Re: Assertion from command-sequence
On Sun, Feb 20, 2022 at 07:20:24PM +0100, Jean-Marc Lasgouttes wrote: > > Le 18/02/2022 à 17:12, Scott Kostyshak a écrit : > > To reproduce, open the User Guide (make sure it is editable, i.e., not > > read only). Then run the following command sequence: > > > > command-sequence inset-forall Caption char-delete-forward; statistics; undo > > > > I get the following assertion: > > Fixed in trunk at 3b28ac46376. > > I really wonder why this special behavior is by default, since it is only > useful for interactive edition. > > I would prefer to have > char-delete-forward confirm > bound to the key. > > What do people think? This would make our basic lfuns more usable for > scripting. That sounds reasonable to me. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Adding a new assertion
On Sun, Feb 20, 2022 at 07:51:43PM +0100, Jean-Marc Lasgouttes wrote: > > Le 18/02/2022 à 17:18, Scott Kostyshak a écrit : > > In whatever part of LyX's code that marks a buffer as dirty, should we > > assert that the document is not read-only? > > > > If I open the User Guide from the Help menu, editing is disabled. But if I > > run: > > > >command-sequence inset-forall Caption char-delete-forward; statistics; > > undo > > > > The buffer is marked as dirty. I'm not sure if something actually > > changed, but I wonder if a general way to catch these types of issues is > > to add an assertion. But perhaps there are some cases where it is hard > > to know if the buffer is dirty (maybe with Undo?) so we mark it as dirty > > just in case? > > Actually, the buffer is marked dirty when a recordUndo happens. > > Several things come to mind: > 1/ in LFUN_BUFFER_FORALL, we do a recordUndo before dispatching each > command. There is no reason for that IMO (it was my doing, but there are no > explanations). > 2/ all undo operations should be no-ops when buffer is read-only (unless I > am missing something important). > > 1/ is done at 48ee2fd0, > 2/ is done at bfe98181. > > Hope I did not overlook something. Thanks! Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] child documents: allow inheritance of bibliography file list (#4427)
On Sun, Feb 20, 2022 at 04:33:40PM +0100, Jürgen Spitzmüller wrote: > Am Sonntag, dem 20.02.2022 um 09:48 -0500 schrieb Scott Kostyshak: > > I was going to say that it seems more simple to just select the > > BibTeX inset in the master document, copy, then paste in the child. > > Sure that's an alternative. I implemented this since it was requested. > > > But I just tried it and indeed Insert > List/Content/References > ... > > and pushing the button is a bit faster (mainly since I had to scroll > > to the bottom in the master document). > > Plus it is easier to update if you changed the master and already have > an inset in the child. True, good to know. Thanks, Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Same commands for different unicodes?
On Sun, 20 Feb 2022 at 23:41, Kornel Benko wrote: > Am Sun, 20 Feb 2022 23:39:00 +0100 > schrieb Thibaut Cuvelier : > > > On Sun, 20 Feb 2022 at 21:53, Thibaut Cuvelier > wrote: > > > > > On Sun, 20 Feb 2022 at 17:39, Kornel Benko wrote: > > > > > >> Am Sun, 20 Feb 2022 17:04:54 +0100 > > >> schrieb Thibaut Cuvelier : > > >> > > >> > On Sun, 20 Feb 2022 at 13:12, Kornel Benko wrote: > > >> > > > >> > > In unicodesymbols we find > > >> > > > > >> > > 0x025b "\\textepsilon""tipa" ... > > >> > > 0x03b5 "\\textepsilon" "textgreek" ... > > >> > > > > >> > > > >> > 0x03b5 is a true epsilon ( > > >> https://unicodemap.org/details/0x03B5/index.html), > > >> > i.e. a letter in the Greek alphabet, while 0x025b is only something > that > > >> > looks like an epsilon ( > https://unicodemap.org/details/0x025b/index.html > > >> ), > > >> > an IPA symbol. For the latter (0x025b), it's rather an "open-mid > front > > >> > unrounded vowel" (according to > > >> > > https://upload.wikimedia.org/wikipedia/commons/8/8f/IPA_chart_2020.svg > > >> ). > > >> > Although the TIPA package is using \textepsilon to enter this > character > > >> ( > > >> > https://mirror.lyrahosting.com/CTAN/fonts/tipa/tipaman.pdf, page > 33), > > >> so > > >> > I'm not sure there's anything to correct. > > >> > > > >> > > > >> > > 0x204e "\\textasteriskcentered" "textcomp" ... > > >> > > 0x*2217* "\\textasteriskcentered" "textcomp" ... > > >> > > > > >> > > > >> > According to Wikipedia (https://en.wikipedia.org/wiki/Asterisk), > > >> 0x204e is > > >> > a "low asterisk" and 0x2217 is the "asterisk operator". It looks > like > > >> > \textasteriskcentered should output a 0x2217 (based my > understanding of > > >> > http://hevea.inria.fr/examples/test/sym.html) and \textasterisklow > a > > >> 0x204e > > >> > (https://www.johndcook.com/unicode_latex.html: it's recognised by > > >> MathGL > > >> > http://mathgl.sourceforge.net/docs_v1/mathgl_en_10.html and STIX > > >> > http://www.ams.org/STIX/bnb/stix-tbl-2006-10-18.asc). I'd say this > is a > > >> > mistake in unicodesymbols. > > >> > > > >> > For the math mode, these two symbols are found as \ast, I have no > idea > > >> > about the semantic difference with the character * (0x002a): > probably > > >> more > > >> > the operator, because it's usually used as times for calculators… > > >> > > >> My problem is more how to handle such cases (there are 44 conflicts in > > >> unicodesymbols). > > >> > > >> Say, we search for '⁎' (== 0x204e), > > >> lyx outputs \textasteriskcentered > > >> and lyxfind.cpp uses '∗' (== 0x2217) > > >> > > >> This means, we cannot find this char. > > >> > > >> I am not interested in the meaning of these unicode chars. The problem > > >> for findadv is that > > >> there are latex commands which create different unicode depending on > moon > > >> phase. > > >> > > > > > > Based on my understanding of this issue, there will always be some > > > discrepancy, as the mapping depends on the context (text, math, or > TIPA, > > > mostly, as I could see). I believe it's hard to mistake the math > mapping > > > with the two others, but I don't see a similar way to tell TIPA > characters > > > from the others, as it looks like they are entered like normal letters > > > (i.e. not separated like the math mode): it's sure the TIPA mapping is > the > > > best one within an IPA inset, but what about outside? I don't know > > > phonetics enough (especially typesetting with LyX) :/. > > > > > > Would you have a script that finds all these occurrences or a list? > Maybe > > > quite a few could be resolved like the asterisk. > > > > > > > Would it be helpful if some duplicate characters were marked as > deprecated? > > For \\'\\textalpha, for instance (I guess it's the same for all Greek > > vowels with tonos/oxia), 0x1F71 is disallowed (see line idna2008 in > > https://util.unicode.org/UnicodeJsps/character.jsp?a=1F71), unlike > 0x3AC. > > That would help. In fact my script already uses this info, but only a very > few > codes are marked as such. > I am attaching a patch to solve the issue for several Greek characters, using the fact that some of them are more or less deprecated. The other patch only adds math versions for some symbols that did not have one. I'm also attaching an annotated version of your list with suggested fixes in many cases (except for the Greek letters in the accompanying patch). I may be wrong, because many cases are subtleties of Unicode and/or phonetics. 0003-unicodesymbols-add-math-versions-of-some-symbols-acc.patch Description: Binary data 0002-unicodesymbols-mark-several-Greek-characters-as-depr.patch Description: Binary data ,x Description: Binary data -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: (No Subject)
Le 20/02/2022 à 22:58, ehud.be...@protonmail.com a écrit : I am working with LyX for about a month and everything works just fine. Today I created a module to customize my document and the editor. A little while after inserting this module I started getting this message every time I open the document, or when trying to export it to pdf. SIGSEGV signal caught! Sorry, you have found a bug in LyX, hope you have not lost any data. Please read the bug-reporting instructions in 'Help-Introduction' and send us a bug report, if necessary.Thanks! Bye. Show Details.. This is very weird. Can you share with us (or privately if you prefer) a file that exhibits this (together with any custom module that may be needed)? The best would be to create a ticket at www.lyx.org/trac. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Same commands for different unicodes?
Am Sun, 20 Feb 2022 23:39:00 +0100 schrieb Thibaut Cuvelier : > On Sun, 20 Feb 2022 at 21:53, Thibaut Cuvelier wrote: > > > On Sun, 20 Feb 2022 at 17:39, Kornel Benko wrote: > > > >> Am Sun, 20 Feb 2022 17:04:54 +0100 > >> schrieb Thibaut Cuvelier : > >> > >> > On Sun, 20 Feb 2022 at 13:12, Kornel Benko wrote: > >> > > >> > > In unicodesymbols we find > >> > > > >> > > 0x025b "\\textepsilon""tipa" ... > >> > > 0x03b5 "\\textepsilon" "textgreek" ... > >> > > > >> > > >> > 0x03b5 is a true epsilon ( > >> https://unicodemap.org/details/0x03B5/index.html), > >> > i.e. a letter in the Greek alphabet, while 0x025b is only something that > >> > looks like an epsilon (https://unicodemap.org/details/0x025b/index.html > >> ), > >> > an IPA symbol. For the latter (0x025b), it's rather an "open-mid front > >> > unrounded vowel" (according to > >> > https://upload.wikimedia.org/wikipedia/commons/8/8f/IPA_chart_2020.svg > >> ). > >> > Although the TIPA package is using \textepsilon to enter this character > >> ( > >> > https://mirror.lyrahosting.com/CTAN/fonts/tipa/tipaman.pdf, page 33), > >> so > >> > I'm not sure there's anything to correct. > >> > > >> > > >> > > 0x204e "\\textasteriskcentered" "textcomp" ... > >> > > 0x*2217* "\\textasteriskcentered" "textcomp" ... > >> > > > >> > > >> > According to Wikipedia (https://en.wikipedia.org/wiki/Asterisk), > >> 0x204e is > >> > a "low asterisk" and 0x2217 is the "asterisk operator". It looks like > >> > \textasteriskcentered should output a 0x2217 (based my understanding of > >> > http://hevea.inria.fr/examples/test/sym.html) and \textasterisklow a > >> 0x204e > >> > (https://www.johndcook.com/unicode_latex.html: it's recognised by > >> MathGL > >> > http://mathgl.sourceforge.net/docs_v1/mathgl_en_10.html and STIX > >> > http://www.ams.org/STIX/bnb/stix-tbl-2006-10-18.asc). I'd say this is a > >> > mistake in unicodesymbols. > >> > > >> > For the math mode, these two symbols are found as \ast, I have no idea > >> > about the semantic difference with the character * (0x002a): probably > >> more > >> > the operator, because it's usually used as times for calculators… > >> > >> My problem is more how to handle such cases (there are 44 conflicts in > >> unicodesymbols). > >> > >> Say, we search for '⁎' (== 0x204e), > >> lyx outputs \textasteriskcentered > >> and lyxfind.cpp uses '∗' (== 0x2217) > >> > >> This means, we cannot find this char. > >> > >> I am not interested in the meaning of these unicode chars. The problem > >> for findadv is that > >> there are latex commands which create different unicode depending on moon > >> phase. > >> > > > > Based on my understanding of this issue, there will always be some > > discrepancy, as the mapping depends on the context (text, math, or TIPA, > > mostly, as I could see). I believe it's hard to mistake the math mapping > > with the two others, but I don't see a similar way to tell TIPA characters > > from the others, as it looks like they are entered like normal letters > > (i.e. not separated like the math mode): it's sure the TIPA mapping is the > > best one within an IPA inset, but what about outside? I don't know > > phonetics enough (especially typesetting with LyX) :/. > > > > Would you have a script that finds all these occurrences or a list? Maybe > > quite a few could be resolved like the asterisk. > > > > Would it be helpful if some duplicate characters were marked as deprecated? > For \\'\\textalpha, for instance (I guess it's the same for all Greek > vowels with tonos/oxia), 0x1F71 is disallowed (see line idna2008 in > https://util.unicode.org/UnicodeJsps/character.jsp?a=1F71), unlike 0x3AC. That would help. In fact my script already uses this info, but only a very few codes are marked as such. Kornel pgpveSA23KwnD.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Same commands for different unicodes?
On Sun, 20 Feb 2022 at 21:53, Thibaut Cuvelier wrote: > On Sun, 20 Feb 2022 at 17:39, Kornel Benko wrote: > >> Am Sun, 20 Feb 2022 17:04:54 +0100 >> schrieb Thibaut Cuvelier : >> >> > On Sun, 20 Feb 2022 at 13:12, Kornel Benko wrote: >> > >> > > In unicodesymbols we find >> > > >> > > 0x025b "\\textepsilon""tipa" ... >> > > 0x03b5 "\\textepsilon" "textgreek" ... >> > > >> > >> > 0x03b5 is a true epsilon ( >> https://unicodemap.org/details/0x03B5/index.html), >> > i.e. a letter in the Greek alphabet, while 0x025b is only something that >> > looks like an epsilon (https://unicodemap.org/details/0x025b/index.html >> ), >> > an IPA symbol. For the latter (0x025b), it's rather an "open-mid front >> > unrounded vowel" (according to >> > https://upload.wikimedia.org/wikipedia/commons/8/8f/IPA_chart_2020.svg >> ). >> > Although the TIPA package is using \textepsilon to enter this character >> ( >> > https://mirror.lyrahosting.com/CTAN/fonts/tipa/tipaman.pdf, page 33), >> so >> > I'm not sure there's anything to correct. >> > >> > >> > > 0x204e "\\textasteriskcentered" "textcomp" ... >> > > 0x*2217* "\\textasteriskcentered" "textcomp" ... >> > > >> > >> > According to Wikipedia (https://en.wikipedia.org/wiki/Asterisk), >> 0x204e is >> > a "low asterisk" and 0x2217 is the "asterisk operator". It looks like >> > \textasteriskcentered should output a 0x2217 (based my understanding of >> > http://hevea.inria.fr/examples/test/sym.html) and \textasterisklow a >> 0x204e >> > (https://www.johndcook.com/unicode_latex.html: it's recognised by >> MathGL >> > http://mathgl.sourceforge.net/docs_v1/mathgl_en_10.html and STIX >> > http://www.ams.org/STIX/bnb/stix-tbl-2006-10-18.asc). I'd say this is a >> > mistake in unicodesymbols. >> > >> > For the math mode, these two symbols are found as \ast, I have no idea >> > about the semantic difference with the character * (0x002a): probably >> more >> > the operator, because it's usually used as times for calculators… >> >> My problem is more how to handle such cases (there are 44 conflicts in >> unicodesymbols). >> >> Say, we search for '⁎' (== 0x204e), >> lyx outputs \textasteriskcentered >> and lyxfind.cpp uses '∗' (== 0x2217) >> >> This means, we cannot find this char. >> >> I am not interested in the meaning of these unicode chars. The problem >> for findadv is that >> there are latex commands which create different unicode depending on moon >> phase. >> > > Based on my understanding of this issue, there will always be some > discrepancy, as the mapping depends on the context (text, math, or TIPA, > mostly, as I could see). I believe it's hard to mistake the math mapping > with the two others, but I don't see a similar way to tell TIPA characters > from the others, as it looks like they are entered like normal letters > (i.e. not separated like the math mode): it's sure the TIPA mapping is the > best one within an IPA inset, but what about outside? I don't know > phonetics enough (especially typesetting with LyX) :/. > > Would you have a script that finds all these occurrences or a list? Maybe > quite a few could be resolved like the asterisk. > Would it be helpful if some duplicate characters were marked as deprecated? For \\'\\textalpha, for instance (I guess it's the same for all Greek vowels with tonos/oxia), 0x1F71 is disallowed (see line idna2008 in https://util.unicode.org/UnicodeJsps/character.jsp?a=1F71), unlike 0x3AC. -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Same commands for different unicodes?
Am Sun, 20 Feb 2022 21:53:28 +0100 schrieb Thibaut Cuvelier : > > This means, we cannot find this char. > > > > I am not interested in the meaning of these unicode chars. The problem for > > findadv is that > > there are latex commands which create different unicode depending on moon > > phase. > > > > Based on my understanding of this issue, there will always be some > discrepancy, as the mapping depends on the context (text, math, or TIPA, > mostly, as I could see). I believe it's hard to mistake the math mapping > with the two others, but I don't see a similar way to tell TIPA characters > from the others, as it looks like they are entered like normal letters > (i.e. not separated like the math mode): it's sure the TIPA mapping is the > best one within an IPA inset, but what about outside? I don't know > phonetics enough (especially typesetting with LyX) :/. > > Would you have a script that finds all these occurrences or a list? Maybe > quite a few could be resolved like the asterisk. Of course I have. It is used for missing entries at (my version of) lyxfind.cpp. Here the list of offending commands so far. Kornel ,x Description: Binary data pgpINTMQUZ5BE.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: unicodesymbols: have several commands for a single symbol?
On Sun, 20 Feb 2022 at 11:27, Enrico Forestieri wrote:
> On Sun, Feb 20, 2022 at 01:29:28AM +0100, Thibaut Cuvelier wrote:
> >
> > On Sat, 19 Feb 2022 at 12:28, Enrico Forestieri wrote:
> >
> > > On Sat, Feb 19, 2022 at 08:47:17AM +0100, Jürgen Spitzmüller wrote:
> > > >
> > > > Am Samstag, dem 19.02.2022 um 02:43 +0100 schrieb Thibaut Cuvelier:
> > > > > Does it look alright to you? If so, I will push these patches.
> > > >
> > > > So if an entry has "", this will be set empty, and if it has nothing,
> > > > it will inherit the former, right? And until now, only "" was
> allowed,
> > > > no missing table entries? I am just asking if I got it right. If so,
> it
> > > > looks good to me.
> > >
> > > I have a doubt about the change in src/Encoding.cpp. The entire map is
> > > scanned for a whole match before performing the usual processing.
> > > This could significantly slow down performance to account for a few
> > > statistically insignificant cases. Maybe an optional parameter could be
> > > added to fromLaTeXCommand() asking explicitly for this pre-check in the
> > > cases where it is really important? Did you check whether the slow down
> > > is actually significant? I have a recollection that fromLaTeXCommand()
> > > was deemed to be already very slow in some cases, perhaps when used for
> > > bibliography processing, but I am not sure.
> > >
> >
> > I'm not sure that this change significantly changes the performance of
> the
> > function: it basically searches through the whole set for each character
> in
> > the input string.
>
> Ok. For sure, it would instead improve performance when the match
> involves the entire string. So, barring any side effect, on average it
> may not matter so much.
>
This shortcut behaves in a different way than the existing code: when a
mapping requires a LyX-level feature (such as Greek text), the shortcut
applies the mapping in all cases, while the complex code below only applies
mapping where the condition applies.
More precisely, if you have an ERT, the DocBook output tries to map Unicode
characters if possible (this is especially important for ePub output,
because these characters would otherwise be lost -- and this kind of
unexpected behaviour is not exactly easy to debug). Take the example of an
ERT with only \textomicron in it: for a random document, LyX couldn't
produce a PDF document because the command is not recognised; if it is
configured for Greek, then \textomicron should be recognised by LaTeX.
However, for DocBook, the ERT will be converted into a Unicode omicron. It
doesn't sound like a big deal to me, but maybe I'm missing part of the
picture.
> > A solution would be to build a hash map to easily find whether a
> particular
> > string is present in unicodesymbols and map it to the corresponding
> Unicode
> > symbol (an integer), for a low memory consumption (4k entries of a number
> > and a string of at most 56 characters,
> > "\\ooalign{\\textdownarrow\\cr\\kern.1em\\textdblhyphen}", that's
> roughly 1
> > MiB with UCS-4 encoding).
>
> I think we should try to avoid premature optimization and only perform it
> when needed.
>
> > Do you already have a stress test for that function? Actually, I don't
> even
> > see a test to ensure correctness. If there's none, I can create such a
> > file, with many representative use cases of fromLaTeXCommand. I'd need
> help
> > to create it, as I have no idea what it is used with in the other places
> it
> > is being used (i.e. I'd need typical insets that call this function with
> > their contents).
>
> I don't think there is any kind of test for that. Initially,
> fromLaTeXCommand() was born to map unicode characters back and forth
> from math and then was used for many other purposes. It is for example
> used in the bibliography inset for mapping latex constructs found in
> bibtex databases to unicode.
>
In these cases, as I can see in the code, fromLaTeXCommand is only used for
one character at a time: I believe there is a high likelihood of having
exact matches in this case.
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Same commands for different unicodes?
On Sun, 20 Feb 2022 at 17:39, Kornel Benko wrote: > Am Sun, 20 Feb 2022 17:04:54 +0100 > schrieb Thibaut Cuvelier : > > > On Sun, 20 Feb 2022 at 13:12, Kornel Benko wrote: > > > > > In unicodesymbols we find > > > > > > 0x025b "\\textepsilon""tipa" ... > > > 0x03b5 "\\textepsilon" "textgreek" ... > > > > > > > 0x03b5 is a true epsilon ( > https://unicodemap.org/details/0x03B5/index.html), > > i.e. a letter in the Greek alphabet, while 0x025b is only something that > > looks like an epsilon (https://unicodemap.org/details/0x025b/index.html > ), > > an IPA symbol. For the latter (0x025b), it's rather an "open-mid front > > unrounded vowel" (according to > > https://upload.wikimedia.org/wikipedia/commons/8/8f/IPA_chart_2020.svg). > > Although the TIPA package is using \textepsilon to enter this character ( > > https://mirror.lyrahosting.com/CTAN/fonts/tipa/tipaman.pdf, page 33), so > > I'm not sure there's anything to correct. > > > > > > > 0x204e "\\textasteriskcentered" "textcomp" ... > > > 0x*2217* "\\textasteriskcentered" "textcomp" ... > > > > > > > According to Wikipedia (https://en.wikipedia.org/wiki/Asterisk), 0x204e > is > > a "low asterisk" and 0x2217 is the "asterisk operator". It looks like > > \textasteriskcentered should output a 0x2217 (based my understanding of > > http://hevea.inria.fr/examples/test/sym.html) and \textasterisklow a > 0x204e > > (https://www.johndcook.com/unicode_latex.html: it's recognised by MathGL > > http://mathgl.sourceforge.net/docs_v1/mathgl_en_10.html and STIX > > http://www.ams.org/STIX/bnb/stix-tbl-2006-10-18.asc). I'd say this is a > > mistake in unicodesymbols. > > > > For the math mode, these two symbols are found as \ast, I have no idea > > about the semantic difference with the character * (0x002a): probably > more > > the operator, because it's usually used as times for calculators… > > My problem is more how to handle such cases (there are 44 conflicts in > unicodesymbols). > > Say, we search for '⁎' (== 0x204e), > lyx outputs \textasteriskcentered > and lyxfind.cpp uses '∗' (== 0x2217) > > This means, we cannot find this char. > > I am not interested in the meaning of these unicode chars. The problem for > findadv is that > there are latex commands which create different unicode depending on moon > phase. > Based on my understanding of this issue, there will always be some discrepancy, as the mapping depends on the context (text, math, or TIPA, mostly, as I could see). I believe it's hard to mistake the math mapping with the two others, but I don't see a similar way to tell TIPA characters from the others, as it looks like they are entered like normal letters (i.e. not separated like the math mode): it's sure the TIPA mapping is the best one within an IPA inset, but what about outside? I don't know phonetics enough (especially typesetting with LyX) :/. Would you have a script that finds all these occurrences or a list? Maybe quite a few could be resolved like the asterisk. -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Adding a new assertion
Le 18/02/2022 à 17:18, Scott Kostyshak a écrit : In whatever part of LyX's code that marks a buffer as dirty, should we assert that the document is not read-only? If I open the User Guide from the Help menu, editing is disabled. But if I run: command-sequence inset-forall Caption char-delete-forward; statistics; undo The buffer is marked as dirty. I'm not sure if something actually changed, but I wonder if a general way to catch these types of issues is to add an assertion. But perhaps there are some cases where it is hard to know if the buffer is dirty (maybe with Undo?) so we mark it as dirty just in case? Actually, the buffer is marked dirty when a recordUndo happens. Several things come to mind: 1/ in LFUN_BUFFER_FORALL, we do a recordUndo before dispatching each command. There is no reason for that IMO (it was my doing, but there are no explanations). 2/ all undo operations should be no-ops when buffer is read-only (unless I am missing something important). 1/ is done at 48ee2fd0, 2/ is done at bfe98181. Hope I did not overlook something. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Assertion from command-sequence
Le 18/02/2022 à 17:12, Scott Kostyshak a écrit : To reproduce, open the User Guide (make sure it is editable, i.e., not read only). Then run the following command sequence: command-sequence inset-forall Caption char-delete-forward; statistics; undo I get the following assertion: Fixed in trunk at 3b28ac46376. I really wonder why this special behavior is by default, since it is only useful for interactive edition. I would prefer to have char-delete-forward confirm bound to the key. What do people think? This would make our basic lfuns more usable for scripting. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Same commands for different unicodes?
Am Sun, 20 Feb 2022 17:04:54 +0100 schrieb Thibaut Cuvelier : > On Sun, 20 Feb 2022 at 13:12, Kornel Benko wrote: > > > In unicodesymbols we find > > > > 0x025b "\\textepsilon""tipa" ... > > 0x03b5 "\\textepsilon" "textgreek" ... > > > > 0x03b5 is a true epsilon (https://unicodemap.org/details/0x03B5/index.html), > i.e. a letter in the Greek alphabet, while 0x025b is only something that > looks like an epsilon (https://unicodemap.org/details/0x025b/index.html), > an IPA symbol. For the latter (0x025b), it's rather an "open-mid front > unrounded vowel" (according to > https://upload.wikimedia.org/wikipedia/commons/8/8f/IPA_chart_2020.svg). > Although the TIPA package is using \textepsilon to enter this character ( > https://mirror.lyrahosting.com/CTAN/fonts/tipa/tipaman.pdf, page 33), so > I'm not sure there's anything to correct. > > > > 0x204e "\\textasteriskcentered" "textcomp" ... > > 0x*2217* "\\textasteriskcentered" "textcomp" ... > > > > According to Wikipedia (https://en.wikipedia.org/wiki/Asterisk), 0x204e is > a "low asterisk" and 0x2217 is the "asterisk operator". It looks like > \textasteriskcentered should output a 0x2217 (based my understanding of > http://hevea.inria.fr/examples/test/sym.html) and \textasterisklow a 0x204e > (https://www.johndcook.com/unicode_latex.html: it's recognised by MathGL > http://mathgl.sourceforge.net/docs_v1/mathgl_en_10.html and STIX > http://www.ams.org/STIX/bnb/stix-tbl-2006-10-18.asc). I'd say this is a > mistake in unicodesymbols. > > For the math mode, these two symbols are found as \ast, I have no idea > about the semantic difference with the character * (0x002a): probably more > the operator, because it's usually used as times for calculators… My problem is more how to handle such cases (there are 44 conflicts in unicodesymbols). Say, we search for '⁎' (== 0x204e), lyx outputs \textasteriskcentered and lyxfind.cpp uses '∗' (== 0x2217) This means, we cannot find this char. I am not interested in the meaning of these unicode chars. The problem for findadv is that there are latex commands which create different unicode depending on moon phase. Kornel pgp6Wo6XibvUO.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Same commands for different unicodes?
On Sun, 20 Feb 2022 at 13:12, Kornel Benko wrote: > In unicodesymbols we find > > 0x025b "\\textepsilon""tipa" ... > 0x03b5 "\\textepsilon" "textgreek" ... > 0x03b5 is a true epsilon (https://unicodemap.org/details/0x03B5/index.html), i.e. a letter in the Greek alphabet, while 0x025b is only something that looks like an epsilon (https://unicodemap.org/details/0x025b/index.html), an IPA symbol. For the latter (0x025b), it's rather an "open-mid front unrounded vowel" (according to https://upload.wikimedia.org/wikipedia/commons/8/8f/IPA_chart_2020.svg). Although the TIPA package is using \textepsilon to enter this character ( https://mirror.lyrahosting.com/CTAN/fonts/tipa/tipaman.pdf, page 33), so I'm not sure there's anything to correct. > 0x204e "\\textasteriskcentered" "textcomp" ... > 0x*2217* "\\textasteriskcentered" "textcomp" ... > According to Wikipedia (https://en.wikipedia.org/wiki/Asterisk), 0x204e is a "low asterisk" and 0x2217 is the "asterisk operator". It looks like \textasteriskcentered should output a 0x2217 (based my understanding of http://hevea.inria.fr/examples/test/sym.html) and \textasterisklow a 0x204e (https://www.johndcook.com/unicode_latex.html: it's recognised by MathGL http://mathgl.sourceforge.net/docs_v1/mathgl_en_10.html and STIX http://www.ams.org/STIX/bnb/stix-tbl-2006-10-18.asc). I'd say this is a mistake in unicodesymbols. For the math mode, these two symbols are found as \ast, I have no idea about the semantic difference with the character * (0x002a): probably more the operator, because it's usually used as times for calculators… -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] child documents: allow inheritance of bibliography file list (#4427)
Am Sonntag, dem 20.02.2022 um 09:48 -0500 schrieb Scott Kostyshak: > I was going to say that it seems more simple to just select the > BibTeX inset in the master document, copy, then paste in the child. Sure that's an alternative. I implemented this since it was requested. > But I just tried it and indeed Insert > List/Content/References > ... > and pushing the button is a bit faster (mainly since I had to scroll > to the bottom in the master document). Plus it is easier to update if you changed the master and already have an inset in the child. 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: [LyX/master] child documents: allow inheritance of bibliography file list (#4427)
On Sun, Feb 20, 2022 at 09:45:29AM +0100, Jürgen Spitzmüller wrote: > Am Sonntag, dem 20.02.2022 um 09:42 +0100 schrieb Jürgen Spitzmüller: > > > If so, I wonder if "copy" might be more clear? > > > > I'm not sure. "Sync" would be another option. > > Also note that it's a push button, which (IMO) clearly indicates that > this is an in-situ process (as opposed to a checkbox which would > indicate constant inheritance). Good point about the push button. I was going to say that it seems more simple to just select the BibTeX inset in the master document, copy, then paste in the child. But I just tried it and indeed Insert > List/Content/References > ... and pushing the button is a bit faster (mainly since I had to scroll to the bottom in the master document). Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Same commands for different unicodes?
In unicodesymbols we find 0x025b "\\textepsilon""tipa" ... 0x03b5 "\\textepsilon" "textgreek" ... or 0x204e "\\textasteriskcentered" "textcomp" ... 0x2217 "\\textasteriskcentered" "textcomp" ... Since we need mapping from latex to unicode while searching through latex-output, it would be handy if we could have the mapping clear. Kornel pgp2IFYVxp41o.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: unicodesymbols: have several commands for a single symbol?
On Sun, Feb 20, 2022 at 01:29:28AM +0100, Thibaut Cuvelier wrote:
>
> On Sat, 19 Feb 2022 at 12:28, Enrico Forestieri wrote:
>
> > On Sat, Feb 19, 2022 at 08:47:17AM +0100, Jürgen Spitzmüller wrote:
> > >
> > > Am Samstag, dem 19.02.2022 um 02:43 +0100 schrieb Thibaut Cuvelier:
> > > > Does it look alright to you? If so, I will push these patches.
> > >
> > > So if an entry has "", this will be set empty, and if it has nothing,
> > > it will inherit the former, right? And until now, only "" was allowed,
> > > no missing table entries? I am just asking if I got it right. If so, it
> > > looks good to me.
> >
> > I have a doubt about the change in src/Encoding.cpp. The entire map is
> > scanned for a whole match before performing the usual processing.
> > This could significantly slow down performance to account for a few
> > statistically insignificant cases. Maybe an optional parameter could be
> > added to fromLaTeXCommand() asking explicitly for this pre-check in the
> > cases where it is really important? Did you check whether the slow down
> > is actually significant? I have a recollection that fromLaTeXCommand()
> > was deemed to be already very slow in some cases, perhaps when used for
> > bibliography processing, but I am not sure.
> >
>
> I'm not sure that this change significantly changes the performance of the
> function: it basically searches through the whole set for each character in
> the input string.
Ok. For sure, it would instead improve performance when the match
involves the entire string. So, barring any side effect, on average it
may not matter so much.
> A solution would be to build a hash map to easily find whether a particular
> string is present in unicodesymbols and map it to the corresponding Unicode
> symbol (an integer), for a low memory consumption (4k entries of a number
> and a string of at most 56 characters,
> "\\ooalign{\\textdownarrow\\cr\\kern.1em\\textdblhyphen}", that's roughly 1
> MiB with UCS-4 encoding).
I think we should try to avoid premature optimization and only perform it
when needed.
> Do you already have a stress test for that function? Actually, I don't even
> see a test to ensure correctness. If there's none, I can create such a
> file, with many representative use cases of fromLaTeXCommand. I'd need help
> to create it, as I have no idea what it is used with in the other places it
> is being used (i.e. I'd need typical insets that call this function with
> their contents).
I don't think there is any kind of test for that. Initially,
fromLaTeXCommand() was born to map unicode characters back and forth
from math and then was used for many other purposes. It is for example
used in the bibliography inset for mapping latex constructs found in
bibtex databases to unicode.
--
Enrico
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Jenkins build is back to normal : Build branch "master" » ubuntu-xenial-qt4-autotools #2147
https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-xenial-qt4-autotools/2147/ -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] child documents: allow inheritance of bibliography file list (#4427)
Am Sonntag, dem 20.02.2022 um 09:42 +0100 schrieb Jürgen Spitzmüller: > > If so, I wonder if "copy" might be more clear? > > I'm not sure. "Sync" would be another option. Also note that it's a push button, which (IMO) clearly indicates that this is an in-situ process (as opposed to a checkbox which would indicate constant inheritance). 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: [LyX/master] child documents: allow inheritance of bibliography file list (#4427)
Am Samstag, dem 19.02.2022 um 14:13 -0500 schrieb Scott Kostyshak: > Cool, thanks for working on this. I'm confused about how this works. > Is it a deep copy of the master's BibTeX or a pointer? e.g., if I > click on "inherit", and then in the master document I change the > bibliography, do I need to change the child again? Yes. It's similar to what we already offer for branches. > If so, I wonder if "copy" might be more clear? I'm not sure. "Sync" would be another option. > Also, after clicking on inherit does the child's BibTeX inset output > LaTeX when compiling the master? It's a normal BibTeX inset. So it outputs LaTeX if it's not in a note or somesuch. 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: unicodesymbols: have several commands for a single symbol?
Am Sonntag, dem 20.02.2022 um 01:15 +0100 schrieb Thibaut Cuvelier: > Empty entries were already allowed. I know. > There is no notion of inheritance, though, I'm only adding a way to > have an alternative way of detecting a symbol. I see. I misunderstood, then. 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
