Re: Include ".vs" in gitignore?

[Joel Kulesza]

On Sat, Mar 18, 2023 at 7:14 AM Jean-Marc Lasgouttes 
wrote:

> Le 18/03/2023 à 12:18, Yu Jin a écrit :
> > Can we do that? Visual Studio always creates some files in the '.vs'
> > subfolder when I open the repository with it.
>
> I guess we can.
>
> JMarc
>

If this step is taken, perhaps also include `.vscode`?

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

Re: Acknowledgment vs. Acknowledgement

[Joel Kulesza]

On Mon, Jan 30, 2023 at 10:05 Scott Kostyshak  wrote:

> On Mon, Jan 30, 2023 at 07:26:31AM +0100, Jürgen Spitzmüller wrote:
> > Am Montag, dem 30.01.2023 um 08:28 +1300 schrieb Andrew Parsloe:
> > > Just to confuse matters, my "New Oxford English Dictionary" (in fact
> > > from the 1990s) has "acknowledgement (also acknowledgment)" whereas
> > > with words like "colour" and "tyre" it has "colour (US color)", "tyre
> > > (US tire)". In other words, it doesn't see the
> > > "acknowledgement/acknowledgment" distinction as a UK/US one.
> >
> > Thanks. According to my (rather superficial) research, both variants
> > seem to be used in both regions to _some_ degree, though the "e"
> > variant seems to be significantly more frequent outside US than within
> > US and Canada, where the other variant seems more common.
> >
> > Some dictionaries, and particular spelling-related blogs and fora do
> > make the distinction explicitly. I have become aware of it while
> > revising the English Additional Features manual, as my (US) English
> > spellchecker (hunspell) nagged about Acknowledgement and suggested
> > Acknowledgment.
> >
> > Such national variety distinctions are always fuzzy when you look
> > closer. The question here probably boils down to what users from that
> > regions would expect.
>
> I wish I could give a helpful perspective from a "native" U.S. English
> speaker, but this word (and its friends "judgment" and "judgement") have
> haunted me for a long time. Just going off of memory, I think I usually
> spell it "acknowledgement" because that makes more sense to me from a
> spelling "rules" perspective, but I remember searching and realizing
> that "acknowledgment" is indeed the U.S. way to spell it. So now I try
> to use that for consistency. But every few months or so, whenever I
> spell it the U.S. way I second-guess myself and think I've made a
> spelling mistake and I spend 10 minutes googling and looking at
> discussions and historical origins and then I spend another 2 minutes
> lamenting that the time I spent googling was not worth the cost of a
> potential spelling mistake.
>
> In summary, I think you are right that in U.S. English the most common
> is "acknowledgment".


In these circumstances and others for style and grammar, I’ve started
turning to the Chicago Manual of Style. It has been a tremendous resource
and “rule book” to help ensure consistency for all of the above.

In this case, section 7.1 of the 17th edition would point us to
Merrimam-Webster’s collegiate dictionary as the preferred source, which
indicates acknowledgment.

Hope this helps,
Joel

P.S., just recently I was writing a paper and LyX had red underlined and
encouraged me to change from acknowledgement to acknowledgment. :-)
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Semantic line feeds

[Joel Kulesza]

On Sun, Dec 18, 2022 at 2:02 PM Scott Kostyshak  wrote:

> On Sun, Dec 18, 2022 at 08:05:30PM +, José Matos wrote:
> > On Sun, 2022-12-11 at 21:16 -0500, Scott Kostyshak wrote:
> > > That would be ideal, but I don't know if anyone will volunteer to do
> > > this.
> > >
> > > Scott
> >
> > I can do it since this is important for lyx2lyx.
> >
> > What I do not like of the new feature is that I get examples like this:
> >
> > $ diff -u old.lyx new.lyx
> > ...
> > -The paradigm is called REPL: Read, Evaluate, Print, Loop.
> > +The paradigm is called REPL:
> > + Read,
> > + Evaluate,
> > + Print,
> > + Loop.
> >
> > So in this case I had previously a sentence in a single line but now it
> > is split into four.
>
> I've noticed this also, and I agree it is not convenient in cases like
> these.
>
> > Was that the initial intent?
>
> I'm not sure. I wonder if the intent was focused on long clauses
> separated by a comma, and not focused on the case of using commas to
> separate a list of short items.
>

While I was uninvolved in the modifications (other than as an advocate), my
understanding of version control systems is that more lines are better and
make for more granular diffs.  I believe this is why the Python
source-formatting utility `black` tends to favor line breaks.  Thus, more
and shorter lines are in keeping with supporting version-control systems,
internal differencing, and conflict resolution.

Hope these thoughts help (and are not off base).

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

Re: Baby steps towards more frequent major releases

[Joel Kulesza]

On Sat, Dec 10, 2022 at 11:04 AM Pavel Sanda  wrote:

> On Sat, Dec 10, 2022 at 10:40:37AM -0700, Joel Kulesza wrote:
> > If you (or someone) can help me provision the build environment to the
> > point where I can build/package, I'd then be able to show potential
> benefit
>
> apt build-dep lyx
>

I saw this with some searching online, and when I tried it, I got:

apt build-dep lyx
Reading package lists... Done
E: You must put some 'deb-src' URIs in your sources.list


I wasn't sure if that meant this fell out of maintenance or was a
legitimate error.  If legitimate, do we know how to overcome it?

Thank you,
Joel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Baby steps towards more frequent major releases

[Joel Kulesza]

On Mon, Nov 28, 2022 at 2:20 AM Pavel Sanda  wrote:

> On Sat, Nov 26, 2022 at 02:42:52PM -0700, Joel Kulesza wrote:
> > On Sat, Nov 26, 2022 at 2:16 PM Jean-Marc Lasgouttes  >
> > wrote:
> >
> > > Le 26/11/2022 ?? 21:17, Scott Kostyshak a écrit :
> > > > 5. We should produce snapshot binaries (i.e., testing releases that
> > > > aren't necessarily at a stage with criteria) more frequently.
> This is
> > > > especially helpful for platform-specific bugs so we can ask the
> > > > reporter if they can reproduce with the latest test release.
> > >
> > > It would actually be great to have nightly builds produced by the CI
> > > platform. I am sure this is doable for several of our platforms. But of
> > > course somebody has to set it up.
> > >
> >
> > As part of my Gitlab explorations, I could take a look at this as well.
> > Does anyone have the "cookbook steps" used to build out LyX distributions
> > (starting with Linux) to encode in the CI?
>
> Well, the release cookbok is here:
> https://wiki.lyx.org/Devel/ReleaseProcedure
> But that's mostly for creating proper tarballs and not for nighties.
>
> Linux world has different packaging formats so you'd need to decide what
> you shoot for.
>

Pavel,

Thanks for these thoughts.  I tried to follow the ReleaseProcedure as a
test with an Ubuntu docker image (a minimal Ubuntu "installation").  Almost
everything needs to be installed, which begs the question: what are the
prerequisites needed to build a release?  I installed obvious ones using
apt-get like gcc, g++, etc., but I'm stuck on Qt.  I installed every
sensible package that could be found, but I'm still unable to "compile a
simple Qt executable" according to ./configure.

If you (or someone) can help me provision the build environment to the
point where I can build/package, I'd then be able to show potential benefit
to Gitlab beyond just an improved ticketing system (part of my motivation
for investigating this in parallel with migrating Trac).

Thank you,
Joel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Baby steps towards more frequent major releases

[Joel Kulesza]

On Sat, Nov 26, 2022 at 2:16 PM Jean-Marc Lasgouttes 
wrote:

> Le 26/11/2022 à 21:17, Scott Kostyshak a écrit :
> > 5. We should produce snapshot binaries (i.e., testing releases that
> > aren't necessarily at a stage with criteria) more frequently. This is
> > especially helpful for platform-specific bugs so we can ask the
> > reporter if they can reproduce with the latest test release.
>
> It would actually be great to have nightly builds produced by the CI
> platform. I am sure this is doable for several of our platforms. But of
> course somebody has to set it up.
>

As part of my Gitlab explorations, I could take a look at this as well.
Does anyone have the "cookbook steps" used to build out LyX distributions
(starting with Linux) to encode in the CI?

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

Re: Get rid of the "Let it run" prompt?

[Joel Kulesza]

On Fri, Nov 25, 2022 at 9:19 AM Jürgen Spitzmüller 
wrote:

> Am Freitag, dem 25.11.2022 um 09:10 -0700 schrieb Joel Kulesza:
> > Perhaps a related use: reporting render time in the status bar.  In
> > particular, I would find this useful for long-rendering documents
> > that I have a sense of time for.  When the time is well exceeded, I
> > can assume that I've introduced a problem and can then kill it.
>
> The status bar is already too crowded. But we could report it via the
> spinner's tooltip.


Sounds good.

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

Re: Get rid of the "Let it run" prompt?

[Joel Kulesza]

On Fri, Nov 25, 2022 at 8:39 AM Scott Kostyshak  wrote:

> On Tue, Nov 22, 2022 at 02:26:27PM -0500, Scott Kostyshak wrote:
> > On Tue, Nov 22, 2022 at 05:51:58PM +0100, Jürgen Spitzmüller wrote:
> > > Am Montag, dem 21.11.2022 um 14:50 -0500 schrieb Scott Kostyshak:
> > > > Nice, thank you!
> > > >
> > > > Should I go ahead with removing the "Let it run" mechanism then?
> > >
> > > Yes.
> >
> > Thanks, I'll work on it.
>
> Done at 6d4ab799. I just used the special timeout value of "-1" to
> disable the dialog. I did not completely remove the timeout
> implementation because (1) it is more complicated than I realize and I
> don't want to mess with it at this point; and (2) I wonder if there is
> still some potential (current or future) use of it? I don't have any in
> mind, but since I hesitated I thought it best to leave it.
>

Perhaps a related use: reporting render time in the status bar.  In
particular, I would find this useful for long-rendering documents that I
have a sense of time for.  When the time is well exceeded, I can assume
that I've introduced a problem and can then kill it.

Thanks to everyone for their continued work on all this,
Joel

P.S. I haven't lost track of the Gitlab responses, but I've been (a)
personally quite busy and (b) faced with many reasonable, but difficult,
requests for capability that I want to be sure I address as fully as
possible.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Thanks!

[Joel Kulesza]

On Fri, Oct 7, 2022 at 8:39 AM Scott Kostyshak  wrote:

> On Thu, Oct 06, 2022 at 06:20:36AM -0600, Joel Kulesza wrote:
>
> > Please contact me with any comments, questions, or concerns.
>
> Very cool. Congrats!
>
> I do have questions, but no worries if you prefer to skip some of them :)
>
> 1. I forget whether you have 2.4.0dev set up, but if you do can you
>compile your .lyx file (which I assume is in 2.3.x format) with
>2.4.0dev and see if there are any differences (you can check with the
>program 'diffpdf' for example, and set comparison to "appearance").
>This is a combined test of lyx2lyx and of master's LaTeX output.
>
> 2. I see there are many authors. How many people actually edited the
>.lyx file? What was your workflow to handle people working
>simultaneously on such a large document? Did you use Git? Dropbox?
>Did you use child documents?
>
> 3. How often did you need ERT? For example,
>
>  $ grep "begin_inset ERT" UserGuide.lyx | wc -l
>  56
>

Scott,

You ask some very interesting questions...  Thanks!

The manual you see is from TeXLive 2018 (locked into a particular version
so the team uses a consistent version).  However, I just received a new
computer with TeXLive 2022.  When I compare 2.4.0a3 versus 2.3.2 (the
version used to prepare that document, again, locked at an older version
across the team), I see notable differences.  The LuaLaTeX-produced 2.3.2
document has 1084 pages and the LuaLaTeX-produced 2.4.0a3 document has 1073
pages.  The difference appears to be the exclusion of content in 2.4.0a3
where TeX code embedded in the child document program listing field is
being processed differently between the two versions.  Also, there are a
couple ERT processing issues of complicated index entries that lead to
makeindex errors in 2.4.0a3 that are ignored in 2.3.2.  It's distressing
that this differs but the fixes are straightforward and it's good to know
about the issues.

Comparing 2.3.2 and 2.4.0a3 with TexLive 2018, I see the same, so it
definitely comes down to how LyX is producing TeX.  However, one TeX-based
difference we run into with such a complicated document is that including
siunitx as we have before is no longer viable without memory tweaks.  I
need to dive into this further.

Regarding authors versus those touching the LyX file, there were about 16
folks who modified the LyX file(s).  We use a git-centric, PR-review-based
approach (with the Atlassian BitBucket tool).  This workflow is the reason
that I tend to periodically raise the idea of significant end-of-line
whitespace (with respect to comparing diffs, whitespace, and the
frequent need to look at under-the-hood .lyx file code).  That said, I use
a review process that involves looking at the code and resulting PDF.  I'm
unsure of how this compares to my colleagues and how they use the code,
PDF, or some combination.  Of course, I'm excited by Yuriy's recent
interest and work on this.

Regarding ERT, the answer surprises me.  We use parent-child documents and
I see the "grep|wc" result of 1013.  I knew we used it, but that frequency
is beyond what I expected (though perhaps sensible regarding how many
cross-pointing index entries we have).  Note that we also have a ~700 line
preamble.  Nevertheless, I'm unsure what we could meaningfully trim and,
speaking for myself, it isn't unmanageable.

One remark, and something I need to construct an MWE from to then post to
the tracker: there are periodically dialogs that accept TeX code (e.g., "~"
or "\texttt") and some that misbehave (generally through literal
interpretation) when supplied.  This appears to differ between 2.3.2 and
2.4.0a3.  Consistent and TeX-compliant behavior (in some manner) would be
ideal for our use case.

Thank you again for these good questions.  Sorry for the delayed response,
but I wanted to provide a thorough analysis and description.

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

Re: Semantic Linefeeds

[Joel Kulesza]

On Mon, Oct 17, 2022 at 08:14 Scott Kostyshak  wrote:

> On Mon, Oct 17, 2022 at 01:21:40PM +0300, Yuriy Skalko wrote:
> > Thanks all for the feedback!
>
> Thanks for working on this, Yuriy. What is the difference in file sizes?
> e.g., of the User Guide? I'm guessing it's negligible, but still curious
> enough to ask.
>
> > Here is a patch to try.
> > Should we also have minimal line length?
>
> I don't have any thoughts on a minimal line length.


I would recommend against an arbitrary limit and instead let the
punctuation logic govern the breaks.

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

Re: Semantic Linefeeds

[Joel Kulesza]

On Sat, Oct 15, 2022 at 3:17 AM Yuriy Skalko  wrote:

> Hello all,
>
> What do you think about adapting semantic linefeeds
> (https://rhodesmill.org/brandon/2012/one-sentence-per-line/) for stored
> paragraph text in LyX files? Mainly to breaks lines only after the
> punctuation marks. Then the diffs in Git for edited documents can be
> much more readable.
>

Yuriy,

Thanks for these thoughts!  I've heard of this approach, but I've never
used it.  I'm reluctant to place the burden on myself to enforce that, but
if it can be codified, then I think it's a good idea and would likely help
review.

There was some discussion on this in 2020 (
https://www.mail-archive.com/search?l=lyx-devel%40lists.lyx.org=Significant+.lyx+EOL+White+Space+Inquiry=15=15),
and I think the consensus was difficulty in reconciling intra-word breaks
and how to update lyx2lyx to perform the necessary conversions.   I wonder
if you see good ways to contend with these obstacles.  Unfortunately, I do
not.

Thank you again,
Joel
-- 
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

[Joel Kulesza]

On Fri, Oct 14, 2022 at 9:38 AM Jürgen Spitzmüller 
wrote:

> Am Freitag, dem 14.10.2022 um 08:51 -0600 schrieb Joel Kulesza:
> > Another area where I hope we can consider background coloring of
> > these types of items is based on whether links get resolved.  That
> > is, a broken cross reference or "citation not found" being colored
> > differently will help resolve the breakage.
>
> Both is done for forthcoming 2.4. See attached screenshot.
>

Awesome—sorry to miss that this change went in.  Thanks for listening and
keeping one step ahead!

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

[Joel Kulesza]

On Sun, Oct 9, 2022 at 1:02 PM Paul A. Rubin  wrote:

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

Colleagues,

Another area where I hope we can consider background coloring of these
types of items is based on whether links get resolved.  That is, a broken
cross reference or "citation not found" being colored differently will help
resolve the breakage.

Thank you,
Joel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Thanks!

[Joel Kulesza]

On Fri, Oct 7, 2022 at 6:42 AM Jean-Marc Lasgouttes <
lasgouttes.lyx@free.fr> wrote:

> Le 07/10/2022 à 13:51, Joel Kulesza a écrit :
> > Awesome, thank you for the feedback!
>
> You are welcome.
>
> BTW, is there feedback we are supposed to provide concerning the gitlab
> ticket migration? I am not pushing anything, it is just to make sure
> that you are not waiting on us and suffering from lack of interest.
>

JMarc et al.,

Yes, I'm still hoping for replies to my March 8 email (
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg217242.html) and
more narrowly my developer-list July 14 email.  Notably, I didn't receive
any user accounts other than JMarc's to add to the private project to get
additional feedback (or I missed them and cannot find them, and I apologize
if that's the case).  Nevertheless, since March 8 and within the
developer-list thread following some additional discussion, I made the
example issue migration public (here:
https://gitlab.com/jkulesza/test_export_import/-/issues) but have received
no feedback subsequently.  So, I am "stuck" between my March 8th steps 2
and 3.

What I would propose at this point unless someone gives the feedback that
what's shown is unworkable, no good, etc., is to cleanup my migration
script, see if I can incorporate attachments and ensure issue number
correspondence, and prove out the process again.  If/when proven, we'll be
at the point of deciding whether to actually perform the migration, or
not.  Because of current work conditions, I'm unsure about the timing of
this, but unless I hear objections I'll pursue this plan.

I'm happy to hear any thoughts on this planned approach.

Thank you,
Joel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Thanks!

[Joel Kulesza]

On Fri, Oct 7, 2022 at 2:36 AM Jean-Marc Lasgouttes 
wrote:

>
> > While I don't challenge you to read this 1,078-page document, I do
> > encourage you to read section 2.1.1, which describes the history of
> > Monte Carlo particle transport generally and the MCNP code
> > specifically.
>
> This is very interesting indeed. But since you ask for comments, I would
> point out that Buffon was a "comte" rather than a "compte"[*]. Laplace
> was one too, a simple "Buffon" would be enough.
>
> Awesome, thank you for the feedback!

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

Thanks!

[Joel Kulesza]

LyX Developers,

The MCNP code recently released a total refresh of its theory and user
manual in support of the upcoming version 6.3 release, which has been
converted to be wholly reliant on LyX.  The manual is available at the top
of https://mcnp.lanl.gov/manual.html with older versions below it available
for comparison.

This manual is maintained by a cross-platform team whose members have
varying degrees of comfort with LaTeX, making its use challenging for some,
so LyX provides an excellent balance of accessibility and capability.

While I don't challenge you to read this 1,078-page document, I do
encourage you to read section 2.1.1, which describes the history of Monte
Carlo particle transport generally and the MCNP code specifically.  I hope
this section is of interest from historical and technical standpoints.
Note that the MCNP code was first released in the late 1970s and is one of
the most recognized codes in its field with well over 10,000 worldwide
users.

Thank you for all that you do to maintain and grow LyX, and please
recognize its importance and impact.

Please contact me with any comments, questions, or concerns.

Thank you again,
Joel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

LYXERR0 / lyxerr Output Discrepancies

[Joel Kulesza]

LyX Developers,

I regularly perform command-line-based execution of LyX and am subject to
the resulting CLI output.  I've noticed messages have several formats
despite both being driven by `src/support/debug.h`.  For example, I see
messages coming from both

Buffer.cpp: LYXERR0("Warning: a buffer should not have two parents!");


and

mathed/MathParser.cpp: lyxerr << "unusual contents found: " << ar << endl;


I have configured no debug verbosity settings.

The Buffer call has more information (in the way of source-file ID and line
number).  The latter message is formatted less "formally" (purely lower
case, no location or other contextual information, etc.).

Is there a reason that these diagnostic messages have different approaches
and forms (maybe to avoid constructing a string to send to LYXERR0)?  If
unintentional, is there a preferred form (mine would be the former)?  If
so, is there interest in me submitting a patch to unify toward a
consistent approach?

I look forward to your thoughts on these matters and how best I can help
unify this output.

In the meantime, please contact me with any comments, questions, or
concerns.

Thank you,
Joel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Output word wrapping

[Joel Kulesza]

On Wed, Jun 1, 2022 at 12:22 AM Daniel  wrote:

> https://wiki.lyx.org/LyX/FeaturePoll2#toc5
>
> Asks for:
>
> "Provide an option to save LyX files such that there is no unnecessary
> word wrapping of content text. [...]"
>
> Isn't that already implemented by setting "Output line length" to 0 (in
> Preferences > Output > General)?
>
> Probably the meaning of the 0 value could be more explicit, as has been
> recently done for the cursor width spin box:
>
> https://www.lyx.org/trac/attachment/ticket/12515/0001-Use-Auto-value-on-cursor-width-spinbox.patch
> .
>
> Daniel
>
>
Along these lines, one point of frustration that I and my colleagues run
into is resolving git conflicts in LyX files.  I wonder whether output line
wrapping logic can be made available that permits an improved experience in
this regard (which, based on the Python `black` utility, may demand more
line breaks rather than fewer).  I look forward to any thoughts and/or
discussion on this point.

Thank you,
Joel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: LyX Bug Tracker Password Reset Behavior

[Joel Kulesza]

On Tue, Mar 8, 2022 at 8:51 AM José Abílio Matos  wrote:

> On Tuesday, 8 March 2022 01.53.10 WET Scott Kostyshak wrote:
>
> > Thanks, Joel! I've been complaining several years that we should switch,
>
> > but I don't do anything about it :). And I still have no plans to
>
> > volunteer.
>
> >
>
> > Scott
>
> There are several examples of transitions like that:
>
> https://lwn.net/Articles/885854/
>
> In that article from LWN there are references to other moves like llvm.
>
> So it not so much is the move is worth, certainly it is in the sense that
> the administration of a infrastructure takes lots of time. The next issue
> is when should it be done, before a release, 6 months after a major
> release, etc...
>
> --
>
> José Abílio
>

Colleagues,

Thanks for reinvigorating this discussion.

Regarding José's link: indeed, I did some similar reading a while ago and
it seems the only constant is change, as projects have migrated around.
Those projects using Trac have variously reported success, and from what I
found it seems like newer versions of Trac have improved exporters relative
to what I understand LyX's version has available.  We effectively have a
SQLite dump available that then needs to be parsed.  Once parsed, we need
to then import into the preferred interface.  For this sort of thing, I
prefer Gitlab over Github (mainly because of the tighter integration of
services—see PS line if interested).  To that end, I tested an import of
~1,500 LyX issues into Gitlab about a year ago, which is about 10% of the
tickets.  That's about the upper limit of import size, which just means
we'll need to do ~10 chunked imports.  I see no problem with this.

To JMarc's question on what works and what doesn't.  Importing issue data
is clunky, but functional.  We cannot import individual comments as Gitlab
comments (as far as I can tell), but we can structure comments in the issue
description to read sensibly.  Importing issue attachments and
cross-referencing the files to the issues is something I couldn't get
working, is complicated, but I have some ideas about how to get working.
It is surely worth looking back at this since a year has elapsed since I
last did this.

Also, a coordination challenge: to get issues properly linked to human
actors (submitters, commenters, etc.), it appears that we'll want to have
individuals register an account with Gitlab *before* the import.  I'm sure
we won't get 100% coverage, but I hope we can "put the word out" on the
various LyX lists to drive this registration, to collect such user IDs, to
ultimately best link the imported data to real people.

To Scott's observation that we likely need *a* volunteer who is highly
motivated and has time...  I'm happy to continue working with this if the
prevailing opinion supports such a migration.  On the subject of when and
how to do this: much prototyping can be done before a "real migration".  I
still have the Python script I was using to process Trac data into
Gitlab-importable artifacts.  The real migration will likely be a matter of
closing issue activity over the course of a weekend to permit export from
Trac and import to Gitlab.  Regarding when that weekend should be: after a
release seems reasonable, but I'm unsure whether we need to hold ourselves
to any such schedule because a significant rift in workflow will result,
and there's likely no "good" time for that.

If we do have the prevailing opinion that we want to move ahead, some next
steps I see:

1.  I would ask active LyX developers/maintainers interested in assisting
me with sanity checks and testing to create a Gitlab.com account and send
me (privately) your user ID.

With that, I can add those individuals to the private project where I've
been doing my prototyping.  I want to keep the project private until I can
get a sanity check from trusted LyX maintainers that I'm not failing to
consider any privacy or security issues.

2. Once confirmed, I'd like to open up the current prototype Gitlab site to
be publicly accessible and solicit broader feedback (likely on this list,
though not limited just to trusted LyX maintainers but all interested
parties).

3. Incorporate the aforementioned feedback into the output processing
that's already there, and perform a prototype migration to a (different)
test project.  This prototype migration would not require any Trac outage,
etc.

With the outcome of the third step, we can determine go/no-go on a real
migration and coordinate when to do that, with particular consideration for
getting all available folks registered beforehand but not bothering
everyone too early in case we can't ensure clear success.

I look forward to everyone's thoughts on these points and this approach.

Thank you,
Joel

P.S. Some remarks on other Gitlab experience: I coordinate a Gitlab-based
project related to experimental and evaluated nuclear data processing here
, which
makes extensive use of 

Re: LyX Bug Tracker Password Reset Behavior

[Joel Kulesza]

On Mon, Mar 7, 2022 at 12:53 PM Scott Kostyshak  wrote:

> On Sun, Mar 06, 2022 at 10:32:06AM -0700, Joel Kulesza wrote:
> > Colleagues,
> >
> > I've tried to rest my "forgotten password" in the LyX bug tracker.
> > However, the emails it sends are failing to reach me (not my inbox or my
> > "junk" folder).
> >
> > Do we know whether everything is working as expected?
> >
> > Sorry for any inconvenience in this regard—I'm quite certain of my
> password
> > so I'm not sure what the issue is...
>
> Hi Joel,
>
> Arg sorry for that frustration. The bug tracker is pretty old, and
> certainly some strange things have happened because of it. I haven't
> heard of any recent strangeness along the lines that you've experienced
> but I'm also not surprised. I wish I could offer to transfer things to
> e.g., GitLab but I just don't have time.
>
> I don't know if there is a way for us to recover your account. Wait
> until someone more knowledgeable than I comes along before you try
> something. One hackish possibility is that I think it is easy to
> *delete* your account. I wonder if we delete your account and you make a
> new account with the same user name if trac will treat it continuously
> (e.g., if we search for bugs created by  it shows both
> old ones and ones with your "new" account).
>
> Scott
>

Scott,

Thanks for these thoughts!  Indeed, JMarc replied a bit after you and I
privately replied to propose a course of action that'll hopefully get me
back to submitting issues.  Thanks to you both for your replies!

Along those lines, you mentioned transitioning to Gitlab.  That's something
I investigated ~1 year ago.  I'm happy to share nascent (and partial) work,
but I'm unsure whether there are any privacy concerns of the metadata that
I propagated, which is why I'm not immediately sharing the link in this
note.

>From that work, I observe that the migration will be somewhat labor
intensive, and many of the formatting "niceties" of legacy issues will be
lost or at least severely diluted.  I'm not entirely happy with the result,
which is why I didn't share progress before now, but perhaps the 90%
solution is acceptable for older issues acknowledging that the 100%
solution for issues and the other tightly integrated interface elements for
future issues (and work) is worth it. I provide this link in case we want
to revisit discussion on this point and to pursue this as an option.

I'm happy to address comments, questions, or concerns in this regard.

Thanks again,
Joel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

LyX Bug Tracker Password Reset Behavior

[Joel Kulesza]

Colleagues,

I've tried to rest my "forgotten password" in the LyX bug tracker.
However, the emails it sends are failing to reach me (not my inbox or my
"junk" folder).

Do we know whether everything is working as expected?

Sorry for any inconvenience in this regard—I'm quite certain of my password
so I'm not sure what the issue is...

Thank you,
Joel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Purpose of outline's "Table of Contents"?

[Joel Kulesza]

On Thu, Feb 24, 2022 at 6:51 AM Daniel  wrote:

> On 22/02/2022 23:51, Joel Kulesza wrote:
> > On Tue, Feb 22, 2022 at 12:30 PM Daniel  > <mailto:xraco...@gmx.de>> wrote:
> >
> > On 2022-02-22 14:02, Thibaut Cuvelier wrote:
> >  > On Tue, 22 Feb 2022 at 13:40, Jürgen Spitzmüller  > <mailto:sp...@lyx.org>
> >  > <mailto:sp...@lyx.org <mailto:sp...@lyx.org>>> wrote:
> >  >
> >  > Am Di., 22. Feb. 2022 um 13:00 Uhr schrieb Daniel
> > mailto:xraco...@gmx.de>
> >  > <mailto:xraco...@gmx.de <mailto:xraco...@gmx.de>>>:
> >  >
> >  > I am wondering what the purpose of the "Table of
> > Contents" in the
> >  > Outliner is. Is it supposed to show those elements that
> > actually
> >  > appear
> >  > in the "Table of Contents"? Or all "Sectioning"/"Headings"
> >  > independently
> >  > of whether they actually appear in the TOC.
> >  >
> >  > Currently, it seems to rather do the latter than the
> former
> >  > because it
> >  > also lists "starred" sectioning entries that don't go
> > into the TOC.
> >  >
> >  >
> >  > Yes. Also Frames in beamer and other structural elements. One
> >  > purpose is to easily move around parts of the document.
> >  >
> >  > Maybe a renaming would be worthwhile in order to not
> > confuse the
> >  > two?
> >  >
> >  >
> >  > I figure the most common term is actually "outline". Or
> "document
> >  > structure".
> >  >
> >  >
> >  > The Outline pane does more than just the sections of the
> > document, it
> >  > would be really weird to rename the ToC "Outline". "Document
> > structure"
> >  > seems better.
> >  > (By the way, Google Docs has a "Outline" pane and Word a
> > "Navigation"
> >  > one, for the same purpose.)
> >
> > I noticed that when one clicks on a "Table of Contents" command
> inset,
> > the Outline with the "Table of Contents" opens. So, I guess that
> > connection is not ideal either currently because not only TOC entries
> > are shown.
> >
> >
> > A few remarks from someone who uses the outline pane heavily to contend
> > with a particularly large and complicated document: please note that
> > many approaches to using the Outline pane exist.  I use the "TOC"
> > entries; however, I heavily use the figure, table, citations,
> > cross-reference, marginal notes, and equation drop-down-based views
> > also.  Accordingly, I recommend not getting too fixated on the
> > terminology in one of many cases.
>
> So, do you mean that the other entries in the outline have also
> terminological or other problems? If it is other problems, then I just
> want to point out that terminology problems are (at least in principle)
> very easy to fix and hence might be worthwhile.
>

Daniel,

I'd actually meant the reverse: I do not see a problem with the current
labeling for any of the components nor would I read into how one uses them
(as a "true" TOC, or merely that of organizational structure).  My thought
is that the content is self evident and thus effort better spent elsewhere.

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

Re: Purpose of outline's "Table of Contents"?

[Joel Kulesza]

On Tue, Feb 22, 2022 at 12:30 PM Daniel  wrote:

> On 2022-02-22 14:02, Thibaut Cuvelier wrote:
> > On Tue, 22 Feb 2022 at 13:40, Jürgen Spitzmüller  > > wrote:
> >
> > Am Di., 22. Feb. 2022 um 13:00 Uhr schrieb Daniel  > >:
> >
> > I am wondering what the purpose of the "Table of Contents" in the
> > Outliner is. Is it supposed to show those elements that actually
> > appear
> > in the "Table of Contents"? Or all "Sectioning"/"Headings"
> > independently
> > of whether they actually appear in the TOC.
> >
> > Currently, it seems to rather do the latter than the former
> > because it
> > also lists "starred" sectioning entries that don't go into the
> TOC.
> >
> >
> > Yes. Also Frames in beamer and other structural elements. One
> > purpose is to easily move around parts of the document.
> >
> > Maybe a renaming would be worthwhile in order to not confuse the
> > two?
> >
> >
> > I figure the most common term is actually "outline". Or "document
> > structure".
> >
> >
> > The Outline pane does more than just the sections of the document, it
> > would be really weird to rename the ToC "Outline". "Document structure"
> > seems better.
> > (By the way, Google Docs has a "Outline" pane and Word a "Navigation"
> > one, for the same purpose.)
>
> I noticed that when one clicks on a "Table of Contents" command inset,
> the Outline with the "Table of Contents" opens. So, I guess that
> connection is not ideal either currently because not only TOC entries
> are shown.
>

A few remarks from someone who uses the outline pane heavily to contend
with a particularly large and complicated document: please note that many
approaches to using the Outline pane exist.  I use the "TOC" entries;
however, I heavily use the figure, table, citations, cross-reference,
marginal notes, and equation drop-down-based views also.  Accordingly, I
recommend not getting too fixated on the terminology in one of many cases.

Please contact me with any questions, comments, or concerns in this matter.

Thank you,
Joel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Question on Multiple Render Passes

[Joel Kulesza]

LyX Developers,

A colleague asked me a question the other day on how LyX operates that I
was unsure of, which I hope you can help me with.  He'd read that an
approach to "speeding up" multiple render-pass LaTeX compilations is to use
draft-mode compiles for all but the final compile and wondered whether this
is what LyX does.  If not, is there a way to invoke this to assess
performance impact?

I'm sorry if I'm missing something obvious.

Any thoughts you can share would be much appreciated.

Thank you,
Joel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Clone issue

[Joel Kulesza]

On Sat, Jan 1, 2022 at 1:10 PM Baris Erkus  wrote:

> On 01-Jan-22 11:02 PM, Joel Kulesza wrote:
>
>
>
> On Sat, Jan 1, 2022 at 12:54 PM Baris Erkus 
> wrote:
>
>> On 01-Jan-22 8:24 PM, Joel Kulesza wrote:
>>
>> On Sat, Jan 1, 2022 at 10:05 AM Baris Erkus 
>> wrote:
>>
>>> On 01-Jan-22 7:17 PM, Kornel Benko wrote:
>>> > Am Sat, 1 Jan 2022 19:11:38 +0300
>>> > schrieb Baris Erkus :
>>> >
>>> >> I am having difficulty to clone the repo with the following command:
>>> >>
>>> >> git clone git://git.lyx.org/lyx
>>> >>
>>> >> or
>>> >>
>>> >> git clone git://git.lyx.org/lyx.git
>>> >>
>>> >> The error is
>>> >>
>>> >> fatal: repository 'https://git.lyx.org/lyx.git/' not found
>>> >>
>>> >> For now, I have cloned the unofficial git repo from github and was
>>> able
>>> >> to compile the program.
>>> >>
>>> >> I have Windows 10 and Git 2.34.1 both x64
>>> >>
>>> > Better
>>> > git clone git://git.lyx.org/lyx
>>> >
>>> > ?
>>> >
>>> >   Kornel
>>> >
>>> Both commands did not work. :(
>>>
>>> I've had issues cloning from git.lyx.org, so I setup a mirror at
>> https://gitlab.com/jkulesza/lyx (git clone
>> https://gitlab.com/jkulesza/lyx.git).
>>
>> I have cloned the source from another mirror on Github, and was able to
>> compile it, so it is OK for now.
>>
>> I just wanted to use the original git repo. The git error is below:
>>
>> fatal: repository 'https://git.lyx.org/lyx.git/' not found
>>
>> I am sure it is trivial but could not catch it.
>>
> What happens if the trailing slash is removed?
>
> - Joel
>
> Does not work. I have tried this. Also tried removing the trailing lyx or
> lyx.git completely.
>
> The git error tells me that git is converting the "git://" protocol to "
> http://; protocol. The addresses "https://git.lyx.org/lyx.git/; and
> "https://git.lyx.org/lyx/; <https://git.lyx.org/lyx/> whether with
> trailing slash or not, do not work on my web browser, so they are indeed
> inaccessible.
>
> Maybe something related to git and the address being anonymous
>

I would not expect these addresses to work in a web browser.  To view the
website related to this hosting service, you can visit https://git.lyx.org.
To clone the repository, one should be able to use `git clone git://
git.lyx.org/lyx`, though this latter step is what I've had trouble with.

Hope these thoughts help.

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

Re: Clone issue

[Joel Kulesza]

On Sat, Jan 1, 2022 at 12:54 PM Baris Erkus  wrote:

> On 01-Jan-22 8:24 PM, Joel Kulesza wrote:
>
> On Sat, Jan 1, 2022 at 10:05 AM Baris Erkus 
> wrote:
>
>> On 01-Jan-22 7:17 PM, Kornel Benko wrote:
>> > Am Sat, 1 Jan 2022 19:11:38 +0300
>> > schrieb Baris Erkus :
>> >
>> >> I am having difficulty to clone the repo with the following command:
>> >>
>> >> git clone git://git.lyx.org/lyx
>> >>
>> >> or
>> >>
>> >> git clone git://git.lyx.org/lyx.git
>> >>
>> >> The error is
>> >>
>> >> fatal: repository 'https://git.lyx.org/lyx.git/' not found
>> >>
>> >> For now, I have cloned the unofficial git repo from github and was able
>> >> to compile the program.
>> >>
>> >> I have Windows 10 and Git 2.34.1 both x64
>> >>
>> > Better
>> > git clone git://git.lyx.org/lyx
>> >
>> > ?
>> >
>> >   Kornel
>> >
>> Both commands did not work. :(
>>
>> I've had issues cloning from git.lyx.org, so I setup a mirror at
> https://gitlab.com/jkulesza/lyx (git clone
> https://gitlab.com/jkulesza/lyx.git).
>
> I have cloned the source from another mirror on Github, and was able to
> compile it, so it is OK for now.
>
> I just wanted to use the original git repo. The git error is below:
>
> fatal: repository 'https://git.lyx.org/lyx.git/' not found
>
> I am sure it is trivial but could not catch it.
>
What happens if the trailing slash is removed?

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

Re: Clone issue

[Joel Kulesza]

On Sat, Jan 1, 2022 at 10:05 AM Baris Erkus  wrote:

> On 01-Jan-22 7:17 PM, Kornel Benko wrote:
> > Am Sat, 1 Jan 2022 19:11:38 +0300
> > schrieb Baris Erkus :
> >
> >> I am having difficulty to clone the repo with the following command:
> >>
> >> git clone git://git.lyx.org/lyx
> >>
> >> or
> >>
> >> git clone git://git.lyx.org/lyx.git
> >>
> >> The error is
> >>
> >> fatal: repository 'https://git.lyx.org/lyx.git/' not found
> >>
> >> For now, I have cloned the unofficial git repo from github and was able
> >> to compile the program.
> >>
> >> I have Windows 10 and Git 2.34.1 both x64
> >>
> > Better
> > git clone git://git.lyx.org/lyx
> >
> > ?
> >
> >   Kornel
> >
> Both commands did not work. :(
>
> I've had issues cloning from git.lyx.org, so I setup a mirror at
https://gitlab.com/jkulesza/lyx (git clone
https://gitlab.com/jkulesza/lyx.git).

Perhaps try there?

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

Re: Git clone terribly slow

[Joel Kulesza]

On Mon, Aug 16, 2021 at 5:00 AM Pavel Sanda  wrote:

> On Mon, Aug 16, 2021 at 07:54:50AM +0200, Christoph Schmitz wrote:
> > git clone git://git.lyx.org/lyx currently sends objects at less than 10
> KiB/s. Cloning eventually fails after hours.
> >
> > Is there anything I can do?
>
> I get here 300 KB/s (EU as well).
>
> One option is to use --depth for clone to download in smaller chunks.
>
> The very last option - there are individuals on github who *seem*
> to mirror git repo so if you are desperate you could try e.g.
> https://github.com/cburschka/lyx
> but no guarantees whatsoever about such sources...
>
> Pavel
>

Another third-party clone is available here: https://gitlab.com/jkulesza/lyx

Best regards,
Joel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Make "wrap" the default in find for 2.4.0?

[Joel Kulesza]

On Wed, Jun 2, 2021 at 6:15 PM Scott Kostyshak  wrote:

> On Tue, Jun 01, 2021 at 11:04:00PM -0600, Joel Kulesza wrote:
> > On Tue, Jun 1, 2021 at 10:27 PM Scott Kostyshak 
> wrote:
> >
> > > I've been using the new find bar in master and it's great! Thank you
> > > Jürgen for the nice feature.
> > >
> > > Is there any interest in enabling the "wrap" checkbox for find as
> default?
> > > I have no idea what most users prefer. I could make a poll on the
> lyx-users
> > > list if there is interest in considering it.
> > >
> >
> > One question on polls and because the ones hosted via email seem
> > potentially inconclusive and subject to distracting discussion: is there
> > merit in hosting the poll using a polling service (Google Forms, Quick
> > Survey [https://github.com/simonv3/quick-survey/] at lyx.org, etc.)?  In
> > this way, I wonder if discussion could be separated from results.
>
> That is interesting. How are those more inclusive?


You may have misread: I wrote inconclusive.  That is, email polls don't
automatically aggregate results and clear choices may be lost amongst
discussion.  While the discussion is valuable, definitive outcomes from a
poll are also important.

Sorry for any confusion.

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

Re: Make "wrap" the default in find for 2.4.0?

[Joel Kulesza]

On Tue, Jun 1, 2021 at 10:27 PM Scott Kostyshak  wrote:

> I've been using the new find bar in master and it's great! Thank you
> Jürgen for the nice feature.
>
> Is there any interest in enabling the "wrap" checkbox for find as default?
> I have no idea what most users prefer. I could make a poll on the lyx-users
> list if there is interest in considering it.
>

One question on polls and because the ones hosted via email seem
potentially inconclusive and subject to distracting discussion: is there
merit in hosting the poll using a polling service (Google Forms, Quick
Survey [https://github.com/simonv3/quick-survey/] at lyx.org, etc.)?  In
this way, I wonder if discussion could be separated from results.


> I'm not sure how relevant the following comparison is given that LyX is
> different, but in case it is helpful for discussion:
>
> LibreOffice Writer, Gedit, Chromium, and Firefox automatically wrap. I'm
> not sure any of them even has an option to not wrap or to prompt. The only
> application I'm aware of that has wrap as an option is Vim (see config
> "wrapscan"), although the default is to wrap.
>

As a vim user, this capability would feel familiar, but I have no strong
preference one way or the other.  However, vim keybindings in LyX would be
a (substantially) different matter.

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

Re: Patches for Python scripts

[Joel Kulesza]

On Fri, Jan 29, 2021 at 3:40 PM Thibaut Cuvelier  wrote:

> - The cosmetic changes are based on PEP8, which is the only style guide
> for Python. Highly similar patches already went into the code base less
> than a year ago (
> http://lists.lyx.org/pipermail/lyx-devel/2020-May/001464.html). Other
> style guides for Python are just more precise than PEP8 (e.g., Google:
> https://stackoverflow.com/a/2815311/1066843). I have yet to see an
> important open-source project that does not use PEP8 style guide. It's as
> unopiniated as opinion could get on Python.
> For now, the Python scripts follow the WTF style guide: every committer
> does what they prefer, without any kind of consistency. Python is very
> different from other languages in that there is a real consensus in the
> community on one style guide (PHP is going in the same direction, but it's
> not yet as commonly used: https://www.php-fig.org/psr/psr-2/). I am not
> proposing one style guide for C++ or Perl code, for instance.
>

Some food for thought based on recent experience...

The idea of code style (and style application automation) is something that
has been on my mind a lot lately. Applying the black utility [
https://github.com/psf/black] for Python and clang-format utility [
https://clang.llvm.org/docs/ClangFormat.html] for C/C++ to several projects
I work on have helped reduce style discussion, ensure uniformity, and
provide cognitive ease as code is considered.  It's to the point that
several projects have early CI static analysis that ensures conformance to
the applicable style.  While one may not love any particular style, having
a standard does help with pattern recognition while reading code.

Regards,
Joel
-- 
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

[Joel Kulesza]

On Fri, Jan 22, 2021 at 3:33 AM José Abílio Matos  wrote:

> On Thursday, January 21, 2021 9:44:09 PM WET Richard Kimberly Heck wrote:
>
> > Yes, I see it, and in master too. Screenshot attached.
>
> >
>
> > Riki
>
> Hi Riki,
>
>   I do not see this on Fedora 33 using both 2.3.6.1 and alpha1 packages.
>
> I am just adding another data point to this report.
>
> --
>
> José Abílio
>

Another data point: I do not see this on macOS 11.0.1 with 2.4.0a1.

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

Re: [Windows] Remove the default binding between buffer-zoom and Alt+0

[Joel Kulesza]

On Fri, Jan 15, 2021 at 7:46 PM Scott Kostyshak  wrote:

> On Fri, Jan 15, 2021 at 08:27:23PM -0500, Richard Kimberly Heck wrote:
> > On 1/15/21 3:57 PM, Yuriy Skalko wrote:
> > >> However, by default, in LyX, this has a very problematic side-effect:
> > >> Alt+0
> > >> resets the zoom level to zero. Personally, I know how to configure
> this
> > >> shortcut, but newcomers may be left puzzled (and leave completely).
> > >>
> > >> Moreover, it's more common to use Ctrl+0 to reset the zoom level, at
> > >> least
> > >> on Windows: most Web browsers do it (at least Firefox, Chrome, and
> > >> IE), all
> > >> Microsoft Office programs. It does not work for LibreOffice or
> > >> Notepad++.
> > >>
> > >> I would propose to change the default binding to Ctrl+0, as it's more
> > >> common (although not ubiquitous), and this would fix the problem of
> > >> changing zoom when you try to insert a character.
> > >>
> > >> What do you think of this?
> > >
> > > There are also zooming shortcuts Alt+"+", Alt+"-". To be consistent
> > > these should also use Ctrl. But Ctrl+"-" is already bound to
> > > Hyphenation Point insert. Is it OK to rebind it to Alt+"-"?
> >
> > I'm pretty used to it as it is. I'm not sure we need to worry too much
> > about consistency here, though I'll be interested to hear what others
> > have to say.
>
> I think I would support changing the bindings to be more consistent with
> other applications. I forget why we have things the way they are.
>

Coming from another OS (macOS), I'd expect Ctrl-+ to be zoom in, Ctrl-"-"
to be zoom out, and Ctrl-0 to be reset zoom (to be the corollaries of the
idiomatic Cmd-... behavior on macOS).  So, I'd support this binding change.

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

Re: Change LyX release numbering to Semantic Versioning

[Joel Kulesza]

On Mon, Jan 11, 2021 at 2:18 PM Richard Kimberly Heck 
wrote:

> On 1/11/21 3:59 PM, José Abílio Matos wrote:
>
> Today in the virtual meeting we discussed several of the issues regarding
> the next major version for the stable release.
>
> I am proposing here to change to a Semantic Versioning scheme. This can is
> best described here:
>
> https://semver.org/
>
> So I am proposing for the next version to be 3.0.0.
>
> The stable bug fix releases for this series would be 3.1.0, 3.2.0,...
>
> If, for instance, there is a problem in the stable version 3.2.0 then we
> can immediately release version 3.2.1.
>
> Since we our release schedule is every two years this will keep us in low
> numbers for a long time.
>
> What do you think?
>
> I would like to hear from Joel about this. Apparently, these numbers
> matter to some people.
>
> Riki
>
Regarding semantic versioning: I feel like LyX already (arguably) uses
that.  The argument I imagine: it's not clear what prompted moving from
version 1->2, but a Python-based conversion script manages forward/backward
compatibility in such a way that I regard the "API" as unchanging with the
various changes that underpin 2.4.0 (maybe I'm mistaken).  I would imagine
a change from 2->3 if, for example, the .lyx file migrated irreversibly
from what it is now to XML.  Otherwise, as JMarc noted once I was already
composing this, the "API" is pretty stable.

Taking Jose's semver example, I'd alternatively summarize as:

So I am proposing for the next version to be 2.4.0.

The stable bug fix releases for this series would be 2.4.1, 2.4.2,...

If, for instance, there is a problem in the stable version 2.4.2 then we
can immediately release version 2.4.3.


So, this is effectively how things operate now except collapsing the fourth
entry into the third.  Once a breaking change occurs, then the jump would
be made from 2->3.

Regarding how these numbers might matter to someone: I've had experience
with organizations that approve software for use based on major version
number.  So, changing major version number can require re-review for use,
which inhibits adoption/continued use.  This is not insurmountable, and
it's a very unique and bizarre concern; however, I did want to raise it as
an issue and why I'm not too enthusiastic about rapid version number
changes.  That said, my belief is that numbers are straightforward to count
and arbitrary anyway, so rapid incrementation doesn't bother me personally.

Thank you,
Joel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: XML stream writer library

[Joel Kulesza]

On Tue, Jan 5, 2021 at 1:19 AM Pavel Sanda  wrote:

> On Mon, Jan 04, 2021 at 09:48:42PM +0100, Thibaut Cuvelier wrote:
> > There are multiple issues here. What is needed to generate HTML and
> DocBook
> > is a simple SAX writer, not a parser. I've done plenty of research about
> > it, there's no XML library that does that. Most of them are using a DOM,
> > which is a total waste of memory for such an application: it stores a
> > complete XML tree in memory before serialising it. With SAX, you just
> need
> > a string backend, which is much more lightweight (by several factors).
>
> After little bit more thinking, is using DOM actually that big issue?
> I mean how much it takes - for document of length n its O(n) in space?
>
> Sure, it might be cut to constant, but practically speaking when you have
> 100 pages document what is the real time/memory consumption. Timewise
> you spent 1s in XML compared to next 30s in conversion figures to pdf or
> whatever format? Spacewise probably one more time than what we
> already allocated for document itself.
>
> If using more heavy-weight caliber xml lib is not pain from API point
> of view (and I do not know, you are the expert here) then we might
> actually consider it, given the difficulties in SAX space?
>

I had a similar thought and will note that I've had good success on other
projects with pugixml.

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

Re: Significant .lyx EOL White Space Inquiry

[Joel Kulesza]

On Mon, Dec 14, 2020 at 1:13 PM José Abílio Matos  wrote:

> On Monday, December 14, 2020 7:00:39 PM WET Richard Kimberly Heck wrote:
>
> > I hadn't considered this case. It will also occur, of course, with
> footnotes
>
> > and, indeed, every kind of inset. I can't think of any reasonable
>
> > alternative to your solution. We could presumably write \space at the end
>
> > of the previous line, but I think that would be harder to implement. The
>
> > lyx2lyx part would actually be quite simple. The changes to the parser,
> and
>
> > to the write routines, would be more involved.
>
> >
>
> > Riki
>
> I disagree, for a cheap and dirty solution, we can (ab)use \SpecialChar.
> :-D
>
> The idea came from the first paragraph in the body of the User's Guide:
>
> \begin_layout Title
>
> The \SpecialChar LyX
>
>  User's Guide
>
> \end_layout
>
> If we used "\SpecialChar space"
>
> every time that a space shows at the end of line we would be ready.
>
> The question is, of course, if this is worth the trouble. :-)
>

José,

Thanks to you and Riki for carrying this conversation forward.  For my
part, moving away from significant EOL whitespace would seem to take us to
a more idiomatic place that reduces the likelihood of unintended side
effects.  I've spent some time thinking about your proposal here and I
can't think of a "better" approach (no matter how I measure better).  For
my part, such an update would be "worth the trouble" and I'd be happy to
help implement it.  Thoughts?

Thank you,
Joel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Unicode characters showing encircled alphanumerics

[Joel Kulesza]

On Wed, Dec 9, 2020 at 8:41 AM Pavel Sanda  wrote:

> On Tue, Dec 08, 2020 at 09:47:53PM -, Guenter Milde wrote:
> > The various answers to
> >
> https://tex.stackexchange.com/questions/7032/good-way-to-make-textcircled-numbers
> > show, that there is no global winner.
> >
> > * \raisebox{.5pt}{\textcircled{\raisebox{-.9pt} {8}}}
> >
> > * \usepackage{pifont}
> >
> >   \ding{172}--\ding{181} % seriffed fonts
> >   \ding{192}--\ding{201} % sans-seriffed fonts
> >
> > * \usepackage{igo}
> >   \whitestone{1}--\whitestone{99}
> >
> > * \usepackage{tikz}
> >\newcommand*\circled[1]{\tikz[baseline=(char.base)]{
> >\node[shape=circle,draw,inner sep=2pt] (char) {#1};}}
> >\begin{document}
> >Numbers aligned with the text:  \circled{1} \circled{2} \circled{3}
> end.
> >\end{document}
> >
> >
> > One could consider providing a set of alias macros
> >
> >   \textcircleda ... \textcircledz
> >
> > with fallback definitions to allow customability by a power user.
>
> Thanks for the research. This seems getting complicated, what is your gut
> feeling about the whole proposal now? Should we try to introduce it all?
>

I've taken the TikZ approach also (e.g.,
https://www.sciencedirect.com/science/article/pii/S0021999120307713#se0170)
after having found it the most suitable for my needs.

If this were built in, it'd be nice.  However, I'm concerned that anything
implemented won't serve someone and also that they may be lost with how
they might need to adjust it to their needs.

One potential middle ground (that may be unsatisfactory): provide an
"advanced" snippets manual that demonstrates these types of things?  This
goes against LyX's general philosophy, but it may be a helpful compromise
that's closer to the client than a wiki, etc.

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

Re: Mac Binary with Qt 5.12.9

[Joel Kulesza]

On Sat, Dec 5, 2020 at 6:44 PM Richard Kimberly Heck 
wrote:

> Hi, all,
>
> Due to bug #12042 (https://www.lyx.org/trac/ticket/12042), Stephan Witt
> has produced an OSX package built with Qt 5.12.9. This is a more
> up-to-date version of Qt than we've been using. If the package works
> well, then we'll replace the binary for 2.3.6 with it. But first, we
> need to make sure it works well! We don't expect there to be any
> problems, but you never know. Could some brave souls test it out and let
> us know how it works?
>
> It can be found here:
>
> http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/
>
> Riki
>

I'm happy to test, and will report back when I've done so.  Is there any
(mis)behavior I should be on the lookout for?

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

Re: An official GitHub mirror for LyX?

[Joel Kulesza]

On Sat, Dec 5, 2020 at 12:51 PM Scott Kostyshak  wrote:

> On Sat, Dec 05, 2020 at 08:43:03PM +0100, Pavel Sanda wrote:
> > On Sat, Dec 05, 2020 at 07:48:23PM +0100, Thibaut Cuvelier wrote:
> > > What do you think of it? I already made a quick search in the mailing
> list,
> > > but I did not the topic being discussed.
> >
> > Looks fine to me as well, though if you don't have strong preference,
> > gitlab might be ideologically better option :)
>
> +1 I would also prefer GitLab.
>
> Scott
>

I've had this site [https://gitlab.com/jkulesza/lyx] acting as a mirror for
my own needs for a while, in case someone would like to see how it
looks/feels.

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

Re: Preference to disable input completion?

[Joel Kulesza]

On Tue, Dec 1, 2020 at 10:10 AM Pavel Sanda  wrote:

> On Tue, Dec 01, 2020 at 07:47:40AM -0700, Joel Kulesza wrote:
> > > Yep, that was the major point why we left continuous spellcheck off
> years
> > > back.
> > >
> > > Now it seems that you missed the new thread about continuous spellcheck
> > > from one month back where left wing of devs come up with the reasoning
> that
> > > many users won't get idea about existing spellcheck in lyx unless it's
> on
> > > by default.
> > >
> >
> > I've never been called left wing, and I'm pretty sure I don't qualify as
> > 'dev,' but this goes beyond reasoning.
>
> To state myself clearly by left wing position I meant the opinion that the
> users
> need someone to guide them, while the right wing opinion tends toward more
> raw
> ui experience when you are on your own.
> When you lean too much to the left there is a danger that power users will
> be
> annoyed by the helper functions (I guess that's what Maria called bloat),
> when
> you lean too much to the right you will make you program hostile to the
> average
> user base.
>

Interesting.  I'd not heard that distinction before—thanks for sharing it.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Preference to disable input completion?

[Joel Kulesza]

On Tue, Dec 1, 2020 at 4:29 AM Pavel Sanda  wrote:

> On Mon, Nov 30, 2020 at 05:54:27PM -0500, Maria Gouskova wrote:
> > I saw a similar discussion on lyx-devel a while back about enabling
> > continuous spellcheck by default, and I almost jumped in with a "please
> god
> > no".


I'm curious why this contribution and the rationale behind it wasn't
given.  Healthy discussion, with opposing views but properly framed, seems
like a good thing.


> This sort of behavior and bloat


I'm unsure where the bloat arises; the capability is there regardless of
its operational state.


> is what sent a lot of us running away
> > from "word processors" back in the early 2000's, and even in MS Word
> there
> > is a way to turn all that stuff off.
>

I believe the discussion was to enable the capability with the user able to
turn it off (rather than the current state: disabled with the user able to
enable it (if he/she realizes LyX has this capability).  This is consistent
with the behavior cited.  Perhaps I misunderstand?


> Yep, that was the major point why we left continuous spellcheck off years
> back.
>
> Now it seems that you missed the new thread about continuous spellcheck
> from
> one month back where left wing of devs come up with the reasoning that many
> users won't get idea about existing spellcheck in lyx unless it's on by
> default.
>

I've never been called left wing, and I'm pretty sure I don't qualify as
'dev,' but this goes beyond reasoning. I have several first-hand accounts
of technically savvy but new-to-LyX users being unaware of this feature
until it was announced to them.  I regret that this is anecdotal, for I
don't have affidavits to present, but I certainly have evidence beyond the
imagination.  I'm unsure about the experience of others.

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

Re: Preference to disable input completion?

[Joel Kulesza]

On Sat, Nov 21, 2020 at 7:36 AM Scott Kostyshak  wrote:

> I want to turn input completion off for text completion but leave it on
> for math completion. Andrew and Joel, if you also want that I already have
> a patch that I think does this that I can use locally. Let me know if you
> want me to post it (it would require you to recompile LyX though).
>

The behavior described here is precisely what I'd like.  Please post, and I
hope we can also find a way to incorporate this into master.

Thank you,
Joel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Preference to disable input completion?

[Joel Kulesza]

On Thu, Nov 19, 2020 at 8:28 PM Scott Kostyshak  wrote:

> Does anyone else find (non-automatic) completion annoying in text mode?


I never use manual autocompletion in text mode (intentionally or
unintentionally), so I have no opinion on its behavior.

However, when in a table and moving rightward through cells, it is my
natural inclination to use tab, which initiates autocompletion, which
infuriates me.  That said, I manually modify tables rarely enough such that
I've not pursued disabling this in some way.

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

Re: Continuous Spellchecker Default Behavior (and Voting?)

[Joel Kulesza]

On Tue, Nov 3, 2020 at 10:16 AM Scott Kostyshak  wrote:

> On Tue, Nov 03, 2020 at 07:14:48AM -0700, Joel Kulesza wrote:
> > On Mon, Nov 2, 2020 at 11:06 PM Stephan Witt  wrote:
> >
> > > Am 02.11.2020 um 19:10 schrieb Joel Kulesza :
> > > >
> > > > On Sun, Nov 1, 2020 at 4:19 PM Richard Kimberly Heck <
> rikih...@lyx.org>
> > > wrote:
> > > > On 11/1/20 4:54 PM, Richard Kimberly Heck wrote:
> > > >
> > > > Attached is the patch.
> > > >
> > > > Riki
> > > >
> > > > I seem to never be able to successfully apply patches.  This is no
> > > exception (I'm on master at e8a28c33c), so I cannot test it (complaints
> > > follow my signature for those interested).  Regardless, after reading
> > > through the changes, they all seem reasonable.  Thank you, Riki, for
> taking
> > > this upon yourself!  I hope that we can move forward from here.
> Please let
> > > me know what I can do to help.
> > > >
> > > > Thank you again,
> > > > Joel
> > >
> > > Perhaps it is a difference in CR/LF of patch and work area?
> > >
> > > The patch has Unix line endings.
> > >
> > > Stephan
> > >
> > > See here:
> > >
> https://stackoverflow.com/questions/6308625/how-to-avoid-git-apply-changing-line-endings
> >
> >
> > That doesn't seem to be it (note: I'm on macOS, so I expect Unix line
> > endings to be OK).
> >
> > I've tried `unix2dos`, `dos2unix`, and --whitespace=fix on the git apply,
> > and they all fail.
>
> Have you tried with "git am"?
>

I have—that was the first approach I tried based on an email suggestion
from some time ago.

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

Re: Continuous Spellchecker Default Behavior (and Voting?)

[Joel Kulesza]

On Mon, Nov 2, 2020 at 11:06 PM Stephan Witt  wrote:

> Am 02.11.2020 um 19:10 schrieb Joel Kulesza :
> >
> > On Sun, Nov 1, 2020 at 4:19 PM Richard Kimberly Heck 
> wrote:
> > On 11/1/20 4:54 PM, Richard Kimberly Heck wrote:
> >
> > Attached is the patch.
> >
> > Riki
> >
> > I seem to never be able to successfully apply patches.  This is no
> exception (I'm on master at e8a28c33c), so I cannot test it (complaints
> follow my signature for those interested).  Regardless, after reading
> through the changes, they all seem reasonable.  Thank you, Riki, for taking
> this upon yourself!  I hope that we can move forward from here.  Please let
> me know what I can do to help.
> >
> > Thank you again,
> > Joel
>
> Perhaps it is a difference in CR/LF of patch and work area?
>
> The patch has Unix line endings.
>
> Stephan
>
> See here:
> https://stackoverflow.com/questions/6308625/how-to-avoid-git-apply-changing-line-endings


That doesn't seem to be it (note: I'm on macOS, so I expect Unix line
endings to be OK).

I've tried `unix2dos`, `dos2unix`, and --whitespace=fix on the git apply,
and they all fail.

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

Re: Continuous Spellchecker Default Behavior (and Voting?)

[Joel Kulesza]

On Mon, Nov 2, 2020 at 11:46 AM Richard Kimberly Heck 
wrote:

> On 11/2/20 1:10 PM, Joel Kulesza wrote:
>
> On Sun, Nov 1, 2020 at 4:19 PM Richard Kimberly Heck 
> wrote:
>
>> On 11/1/20 4:54 PM, Richard Kimberly Heck wrote:
>>
>> Attached is the patch.
>>
>> Riki
>>
>
> I seem to never be able to successfully apply patches.  This is no
> exception (I'm on master at e8a28c33c), so I cannot test it (complaints
> follow my signature for those interested).  Regardless, after reading
> through the changes, they all seem reasonable.  Thank you, Riki, for taking
> this upon yourself!  I hope that we can move forward from here.  Please let
> me know what I can do to help.
>
> Is this on stable or master? The patch will only apply to master.
>
> Riki
>
master at e8a28c33c is where I tried and failed.

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

Re: Continuous Spellchecker Default Behavior (and Voting?)

[Joel Kulesza]

On Sun, Nov 1, 2020 at 4:19 PM Richard Kimberly Heck 
wrote:

> On 11/1/20 4:54 PM, Richard Kimberly Heck wrote:
>
> Attached is the patch.
>
> Riki
>

I seem to never be able to successfully apply patches.  This is no
exception (I'm on master at e8a28c33c), so I cannot test it (complaints
follow my signature for those interested).  Regardless, after reading
through the changes, they all seem reasonable.  Thank you, Riki, for taking
this upon yourself!  I hope that we can move forward from here.  Please let
me know what I can do to help.

Thank you again,
Joel

--

> git am 0001-Make-default-TRUE-for-continuous-spellcheck.patch
Applying: Make default TRUE for continuous spellcheck.
.git/rebase-apply/patch:87: trailing whitespace.
#
.git/rebase-apply/patch:93: trailing whitespace.
# This can be used to erase lines (return (True, "")) or to modify
.git/rebase-apply/patch:95: trailing whitespace.
#
.git/rebase-apply/patch:116: trailing whitespace.
#   (the new default is true, so this keeps behavior the same for
error: patch failed: lib/scripts/prefs2prefs.py:4
error: lib/scripts/prefs2prefs.py: patch does not apply
error: patch failed: lib/scripts/prefs2prefs_prefs.py:4
error: lib/scripts/prefs2prefs_prefs.py: patch does not apply
Patch failed at 0001 Make default TRUE for continuous spellcheck.
hint: Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Continuous Spellchecker Default Behavior (and Voting?)

[Joel Kulesza]

All,

Thanks for your consideration and good discussion on default continuous
spellchecker behavior subsequent to
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg213704.html.

I've created this separate thread to avoid continuing to hijack the other
thread on dictionary inclusion and to ask whether it makes sense to call a
vote similar to what Jürgen initiated here
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg212545.html.

The two options I imagine are (A) keep continuous spellchecking disabled by
default or (B) make continuous spellchecking enabled by default (with
appropriate supporting elements of preference propagation, etc.).

If this makes sense, I would ask a core contributor to initiate a vote
here.

Of course, I'd be happy to see the discussion continue here as well.  If a
change is warranted as a result of the vote, I'd also be happy to help
contribute to that (open tracker item, contribute code, etc.).

Thank you again,
Joel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Spellchecking dictionaries in LyX 2.4 installer

[Joel Kulesza]

On Fri, Oct 30, 2020 at 11:40 AM Richard Kimberly Heck 
wrote:

> On 10/30/20 12:55 PM, Pavel Sanda wrote:
> > On Fri, Oct 30, 2020 at 10:47:58AM -0600, Joel Kulesza wrote:
> >> Further, I'd like to see continuous spellchecking enabled by default
> >> (countless folks who I've introduced LyX to ask why that isn't the
> case).
> > Because the is another half of countless folks who hate that by default
> (or at least that was the impression last time we discussed this in users
> list... ;)
> > In such case it seems more wise not to break the defaults.
>
> Yes, that was the reason...
>
> Joel, did those users find it by themselves? Or were they wondering if
> LyX had it at all?
>

Some didn't even think to ask the question of whether it was available but
once demonstrated there was an "oh wow" moment.  As such, I'd be in favor
of exposing capability and letting someone then pursue how to make it stop
rather than press on in ignorance of its existence.

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

Re: Spellchecking dictionaries in LyX 2.4 installer

[Joel Kulesza]

On Fri, Oct 30, 2020 at 10:09 AM Richard Kimberly Heck 
wrote:

> On 10/30/20 5:17 AM, Yuriy Skalko wrote:
> > Hello LyX developers,
> >
> > I've tried testing installer of LyX 2.4 on Windows 10 and it works
> > without any problems, thanks for preparing it.
> >
> > After running the installer, I have proposition to include
> > spellchecking dictionaries for Russian and Portuguese by default into
> > this installer. These two are among the ten most popular languages,
> > even more popular than German that has dictionary installed by default
> > (sorry, I know nothing about spellchecking Chinese and Hindi).
> >
> > As I've checked, both dictionaries take less than 1MB disk space when
> > compressed.
> >
> > Or maybe add more languages (installer for LyX 2.4 now is 15 MB less
> > than installer for LyX 2.3)?
> >
> > What are your thoughts about this?
>
> I think this is a reasaonable idea. What do we include by default now?
>
> Riki
>

Agreed—I'd like to see all languages included by default (or at least a
substantial set: top 25 most prevalent, etc.).

Further, I'd like to see continuous spellchecking enabled by default
(countless folks who I've introduced LyX to ask why that isn't the case).

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

Re: git pull hangs

[Joel Kulesza]

On Tue, Oct 27, 2020 at 10:16 AM Marco Morandini 
wrote:

> > The git server is run by Open Source Labs at Ohio State University. It
> > would be surprising if you were blacklisted there. Have you checked with
> > your IT folks about whether they are prohibiting some traffic?
>
> Apologize for bothering you again about this,
> but we really need an help or a suggestion
> from someone else from the other side of the wall,
> since here we have exhausted the tests we can think of.
>
>
Colleagues,

Note that I have issues with accessing lyx.org's git instance because of
firewall rules.  As such, I mirror the LyX repository for myself.

https://gitlab.com/jkulesza/lyx

Perhaps you can try pulling from there (as a test and/or as a workaround)?

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

Re: New inset for \nopagebreak

[Joel Kulesza]

On Thu, Oct 8, 2020 at 1:56 PM Pavel Sanda  wrote:

> (these are reports so float environment are
> not suitable).
>

Why is this?

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

Re: Font size names

[Joel Kulesza]

On Mon, Aug 10, 2020 at 9:37 AM Kornel Benko  wrote:

>
> I have not found 'huger' in the dictionary, so Giant is OK for me.
> But I would drop footnotesize and scriptsize and use smaller+smallest and
> use the GUI
> names here.
>

Would it be too cluttered to have, for example, "smaller (footnotesize)"
and "smallest (scriptsize)" to help users more familiar with LaTeX
understand the outcome?  These terms are specific to LaTeX, but I'm not
sure they would confuse non-LaTeX LyX users if given with the other size
labels.

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

Re: #10571: Tabs not showing properly in macOS full (and split) screen

[Joel Kulesza]

On Sun, Aug 2, 2020 at 2:56 AM Stephan Witt  wrote:

>
> Does it work as expected for you and on Linux? Can anyone test it on
> Windows, please?
>

I can test on Windows 10 with a 4K display, but I cannot build.  If you can
send an installer, I'll give it a try.

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

Re: LyX-Code layout

[Joel Kulesza]

On Sat, Aug 1, 2020 at 3:51 AM Jean-Marc Lasgouttes 
wrote:

> Le 1 août 2020 08:41:32 GMT+02:00, Richard Kimberly Heck 
> a écrit :
> >No, but there was some discussion. I suspect this one could also be
> >changed.
> >
> >Maybe start a new thread with a subject-line like s/LyX-Code/Code/.
> >Then
> >again, I'd certainly want to hear from JMarc, and he won't be back for
> >a
> >while
>
> If you were to ask me, I would answer that LyXCode should be killed (i.e.
> moved to a legacy module) and that we should add something based on alltt
> instead. LyXCode is just bad LaTeX and is flawed. If I remember well, one
> can have one empty line but not two consecutive ones, for example. And it
> does not accept multiple spaces without using ~.
>
> This new thing could be named Code, although the name does not strike me
> as very good. We have Listings for code.
>

>From my interactions with users, renaming LyXCode would help reduce
confusion.  I agree with JMarc that Code isn't necessarily more clear (and
is generally handled by code listings).  Other applications/HTML have
called this "Preformatted Text".  This is lengthy, but maybe more clear?

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

Re: More lay description for "Use old style figures"?

[Joel Kulesza]

On Tue, Jul 14, 2020 at 9:10 AM José Abílio Matos  wrote:

> On Tuesday, 14 July 2020 15.49.41 WEST Joel Kulesza wrote:
> > On a personal note, this has been an interesting discussion, and I
> > appreciate it, but I sympathize with Scott and would be totally confused
> by
> > "old style figure."  Right or wrong, the first thing I thought of was a
> > graphical filter that would have rendered something similar to a
> > 15th-century illuminated manuscript.
>
> I agree with Joel.
> BTW another useful option would be xkcd graphics:
> https://xkcd.com/1945/


This is even more accessible for easy adoption:
https://matplotlib.org/3.1.1/api/_as_gen/matplotlib.pyplot.xkcd.html

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

Re: More lay description for "Use old style figures"?

[Joel Kulesza]

On Tue, Jul 14, 2020 at 12:35 AM Jürgen Spitzmüller  wrote:

>
> As you wish, but I don't think this will help many people. I really
> doubt "antique numerals" and "medieval-style numerals" is so much more
> known than "old style figures". I'd rather describe the feature.
>

One additional thought for everyone's consideration: it seems like this
becomes a matter of whether LyX is approached from a LaTeX or more generic
typographical perspective.  From the LaTeX standpoint, figure is well
defined and does not (seemingly) correlate to what's being discussed.  I
imagine this is what caused Scott's confusion.  Conversely, from a rigorous
typographical perspective (and for consistency with other software),
perhaps "figure" is the right term.

Regarding who the average user is: are we more likely to find LyX users who
are familiar with LaTeX or typography?  I suspect the former.  If so, the
word "figure" immediately makes one think "picture" whereas numeral calls
to mind a number/character.  I can imagine how hard it will be to convince
colleagues that "old style figure" is more clear even if it is convention
(think metric versus imperial units).

On a personal note, this has been an interesting discussion, and I
appreciate it, but I sympathize with Scott and would be totally confused by
"old style figure."  Right or wrong, the first thing I thought of was a
graphical filter that would have rendered something similar to a
15th-century illuminated manuscript.

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

LyX 2.3.5.1/2.3.5-1 Naming Inconsistency

[Joel Kulesza]

LyX Developers,

Recently, I was working with lyx-2.3.5.1.tar.gz (retrieved from
http://ftp.math.utah.edu/pub/lyx/stable/2.3.x/).

The filename is 2.3.5.1 but extracts, by default (using tar -zxvf), to the
directory lyx-2.3.5-1.

I know this is an abnormal situation/release, but this inconsistency makes
scripted handling of the file inconvenient.

Should/can the filename and resulting directory be made consistent in the
future?

Thank you,
Joel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: New Section Toolbar Button and Depth-setting Suggestion

[Joel Kulesza]

On Fri, Jun 5, 2020 at 5:57 PM Jean-Marc Lasgouttes 
wrote:

> Le 05/05/2020 à 05:11, Joel Kulesza a écrit :
> > LyX Developers,
> >
> > Sorry, I'm behind the times.  However, recent conversations had me pull
> > the latest `master` and I observed the new "Section" button in the
> > toolbar between Description and Increase Depth.
> >
> > I tried it, and I like it.  However, given its position next to
> > Increase/Decrease depth, does it make sense to enable these to
> > demote/promote through the levels of section/subsection/etc., as
> > appropriate to the document class?
>
> This should work now in latest master.
>

Thanks you for this improvement!  I tested and this behaves how I would
expect.

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

Re: Significant .lyx EOL White Space Inquiry

[Joel Kulesza]

On Fri, May 29, 2020 at 9:49 AM Pavel Sanda  wrote:

> On Thu, May 28, 2020 at 10:27:54AM -0600, Joel Kulesza wrote:
> > Finally, significant EOL white space seems unidiomatic in a "source
> file,"
> > which is what a .lyx file effectively is.
> >
> > This is an expert-use situation, but *I wonder if we have a way to
> overcome
> > the need for significant EOL white space.*
>
> Well, it's all in the code, so one could certainly write patch witch moves
> the whitespace to the next line.


I understand.  I was mainly asking to see whether there is a historical
reason for "needing" EOL white space, or whether it came along at some
point and has persisted.


> The issue is that any oversight in such
> patch would lead to catastrophic dataloss bugs for everyone else and one
> has to ask whether this cornercase is worth the risk.
>

Perhaps not, but it still begs the question whether steps are worth taking
to become a more idiomatic format.


> My take is that
> - if you mess with .lyx you need to respect its whitespacing and
>   set your editor accordingly
>

A fair point, and that's what I've done.  But, it's easy for someone to not
take this step and get burned by it at least once.


> - the real solution would be to actually do document comparison
>   feature right, so one does not need to edit raw .lyx file...
>

Agreed.  I see a few areas for improvement here.  First, I've seen "Track
changes" flag false positives and give false negatives.  So, improving
robustness in this markup would be good.  Second: the ability to provide
comment/replies as wording is iterated upon would be valuable.  That is the
main behavior I seek when performing document review: the ability to
provide specific actionable feedback (perhaps with discussion) on specific
components of the text.  That's why a git-based review system is nice
(Gitlab, Github, Bitbucket, etc.).

Finally, improving the integration with revision tracking would be good.  A
recent criticism I heard was "why do I have to count the number of
revisions back; why not just specify a commit/branch point to compare
with?".  I explained why, but that is valid feedback from a git-centric
view.  I wonder if specializing the version control behavior for git would
be valuable to augment the more generic interface currently available.

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

Significant .lyx EOL White Space Inquiry

[Joel Kulesza]

LyX Developers,

I've run into the situation multiple times that .lyx file EOL white space
(usually, a single space) can be significant.  I've found this to be
particularly true before inline equations. This becomes problematic if
someone's editor (automatically) strips EOL white space, which will lead to
incorrect spacing in the LyX file and any generated files.

I've run into this where I (and a colleague, independently) was using a
text editor to perform merge-conflict resolution in a git-stored LyX
document that a team is collaborating on.  He, I, and maybe others have
found such fixups easier to do in a text editor versus in LyX itself.  I
have prevented my editor from "fixing up" .lyx files.  However, if
someone's editor does this, then it is easy to perform merge-conflict
resolution and only later find this problem (perhaps much later, if white
space differences are ignored in their differencing workflow).  Finally,
significant EOL white space seems unidiomatic in a "source file," which is
what a .lyx file effectively is.

This is an expert-use situation, but *I wonder if we have a way to overcome
the need for significant EOL white space.*

Any thoughts that can be provided are appreciated.

Thank you,
Joel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: New Section Toolbar Button and Depth-setting Suggestion

[Joel Kulesza]

On Wed, May 13, 2020 at 2:35 AM Jean-Marc Lasgouttes 
wrote:

> Le 13/05/2020 à 08:39, Jürgen Spitzmüller a écrit :
> > Am Dienstag, den 12.05.2020, 20:07 +0200 schrieb Jean-Marc Lasgouttes:
> >> This would be the patch below
> >
> > pas de patch ci-dessous
>
> Le voilà Monseigneur.
>

Awesome, thanks for the discussion and quick work on this!  However, a dumb
question:

How do you apply that patch?

When I try with `git apply`, it claims it doesn't apply (see below my
signature).  I'm working from master at
2663e3845e6cc33ec543510aec16c7a37841e26d.  This is a straightforward
change, so I'm surprised to see a problem (unless I'm that problem).

Thanks,
Joel

--

> git apply --check
0001-Use-combined-toolbar-icons-for-depth-in-de-crement-a.patch
error: patch failed: lib/ui/stdtoolbars.inc:124
error: lib/ui/stdtoolbars.inc: patch does not apply
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Cleaning patches

[Joel Kulesza]

On Thu, May 7, 2020 at 5:14 PM Thibaut Cuvelier  wrote:

> Dear list,
>
> While working on DocBook support (
> https://gitlab.com/gadmm/lyx-unstable/-/merge_requests/3), I made a bit
> of clean-up, i.e. correcting one typo and updating lyx2lyx 2.4 to respect a
> bit better the PEP8 (i.e. the official code conventions for Python,
> https://www.python.org/dev/peps/pep-0008/). To automate PEP8 corrections,
> there is already a tool that does it quite well:
> https://github.com/PyCQA/pycodestyle.
>

As an alternative for your consideration, a utility I've found useful is:
https://github.com/psf/black

If you haven't tried it, I recommend it.

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

New Section Toolbar Button and Depth-setting Suggestion

[Joel Kulesza]

LyX Developers,

Sorry, I'm behind the times.  However, recent conversations had me pull the
latest `master` and I observed the new "Section" button in the toolbar
between Description and Increase Depth.

I tried it, and I like it.  However, given its position next to
Increase/Decrease depth, does it make sense to enable these to
demote/promote through the levels of section/subsection/etc., as
appropriate to the document class?

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

Re: [LyX/master] Start reporting missing citations and broken references in LaTeX build.

[Joel Kulesza]

> On Mar 14, 2020, at 08:39, Jürgen Spitzmüller  wrote:
> 
> Am Samstag, den 14.03.2020, 08:25 -0600 schrieb Joel Kulesza:
>> One thing that's been on my mind for a while is coloring the broken
>> elements differently than default; however, it was not clear to me
>> how to achieve that in a straightforward way.
> 
> I've done this as well. See
> https://www.lyx.org/trac/ticket/11503
> 
> Jürgen

Awesome, thank you again!

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

Re: [LyX/master] Start reporting missing citations and broken references in LaTeX build.

[Joel Kulesza]

On Sat, Mar 14, 2020 at 8:19 AM Jürgen Spitzmüller  wrote:

> Am Samstag, den 14.03.2020, 14:29 +0100 schrieb Daniel:
> > > How about a dedicated outliner entry "Broken citations and
> > > references"?
> > > This would be easiest to implement, and it would give you both a
> > > quick
> > > report and the possibility to navigate to the broken insets
> > > quickly.
> > >
> > > Jürgen
> >
> > Yes, I think that would be helpful.
>
> Implemented in master.
>

This is awesome, thank you!  Seeing this information before the PDF is
created is excellent.  One thing that's been on my mind for a while is
coloring the broken elements differently than default; however, it was not
clear to me how to achieve that in a straightforward way.

Thanks again,
Joel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: How to Specify PDF Attachments?

[Joel Kulesza]

On Thu, Feb 27, 2020 at 6:56 AM Pavel Sanda  wrote:

> On Thu, Feb 27, 2020 at 06:50:45AM -0700, Joel Kulesza wrote:
> > > Thinking more, more straightforward solution to your problem would be
> just
> > > new check box ("Include file as pdf attachment as well") in the
> listings
> > > dialog,
> > >
> >
> > How would this work for attaching images, sound files, etc.?
>
> It won't, this was for the case you wanted to use listings.
>

I see and understand, thanks.

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

Re: How to Specify PDF Attachments?

[Joel Kulesza]

On Thu, Feb 27, 2020 at 5:01 AM Pavel Sanda  wrote:

> On Wed, Feb 26, 2020 at 09:50:21PM -0700, Joel Kulesza wrote:
> > Yes, I see now what is meant.  I was reading previous pointers to
> External
> > Material as suggestions that PDFPages would already do what I wanted.
>
> Thinking more, more straightforward solution to your problem would be just
> new check box ("Include file as pdf attachment as well") in the listings
> dialog,
>

How would this work for attaching images, sound files, etc.?

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

Re: How to Specify PDF Attachments?

[Joel Kulesza]

On Wed, Feb 26, 2020 at 3:46 PM Dr Eberhard Lisse  wrote:

> I use the listings package to include config files and program listings
> and the like, but you can't copy and paste these from the PDF, or rather
> they are mangled to be quite useless.
>
> Any way of achieving this (either as attachment (or even via Copy &
> Paste) would be rather great :-)-O
>

What I'm proposing will directly serve your need.  And yes, electronic
attachments to PDF files is a great capability that, unfortunately, few
people are aware of.

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

Re: How to Specify PDF Attachments?

[Joel Kulesza]

On Wed, Feb 26, 2020 at 2:01 PM Pavel Sanda  wrote:

> On Wed, Feb 26, 2020 at 07:45:20AM -0700, Joel Kulesza wrote:
> > Sorry if I'm being dense, but what do you mean by "external template"?
> An
>
> Template used by Insert->File->External Material.
> You can find example templates in lib/xtemplates and I suggest you spend
> some time understanding this machinery before reinventing the (whole)
> wheel.
>

Yes, I see now what is meant.  I was reading previous pointers to External
Material as suggestions that PDFPages would already do what I wanted.
Thanks!
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: How to Specify PDF Attachments?

[Joel Kulesza]

On Wed, Feb 26, 2020 at 11:37 AM Jean-Marc Lasgouttes 
wrote:

> Le 26/02/2020 à 18:34, Jean-Pierre Chrétien a écrit :
> > Sure, I don't understand what's wrong with a plain hyperlink.
>
> What I understand is that, whenever LyX outputs a file name (listings,
> graphics, etc.), it would be possible to wrap it into a magic macro that
> creates an attachment and bundles the file. Am I right?
>

That's along the lines of what I'm thinking, though I would want to be able
to have such inclusion as opt-in.  I'd propose bundling with the
`embedfile` package.  I will send an example of a PDF with electronic
attachments later tonight to give a MWE (versus the MajorWE I linked
previously).

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

Re: How to Specify PDF Attachments?

[Joel Kulesza]

On Wed, Feb 26, 2020 at 9:53 AM Kornel Benko  wrote:

> Am Wed, 26 Feb 2020 07:45:20 -0700
> schrieb Joel Kulesza :
>
> ...
> > Sorry if I'm being dense, but what do you mean by "external template"?
> Insert->File->External Material...->Template: PDF Pages
>

This is for inserting PDF files into PDF files, right?  I want to insert a
text/image/etc. file into a PDF file as an electronic attachment.

In this way, a person reading the encapsulating PDF can retrieve the
text/image/etc. in its raw form and work with it that way.

Would it be beneficial to post another example of my desired end result
beyond what is provided in the OSTI link?

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

Re: How to Specify PDF Attachments?

[Joel Kulesza]

On Wed, Feb 26, 2020 at 6:33 AM Pavel Sanda  wrote:

> On Wed, Feb 26, 2020 at 06:15:20AM -0700, Joel Kulesza wrote:
> > > I think the most obvious candidate is external material machinery.
> >
> > This means that I???ll have to specify the file name twice, right?  It
> is often the case that I want/need to list the file but also want to
> include it for the readers convenience. The frustration of files being
> renamed and having to keep them updated in multiple places is why I???m
> becoming tired of ERT. This, and having multiple items for each file (a
> program listing and the ERT).
>
> Well, if the external template can spit out whatever tex code, right? So
> it could print the command for material embedding, but it could also print
> out some variable/label which contains the name of the file (like
> emebdding_no_01=file.mp3). You would need to define two strings -
> emebdding_no_01 && file.mp3, but from then you could change filename string
> at one place as much as you want while keeping the label name constant and
> using it within the document (through e.g. insetinfo or ERT).
>

Sorry if I'm being dense, but what do you mean by "external template"?  An
example application:

I am writing a report with LyX and want to show a Python source-code file
(myfile.py) in it with the listings package via a Program Listing.  I also
want to attach the file electronically to the PDF so  a user can directly
retrieve and open it.  The Python file is unrelated to LyX/TeX and should
not have code to point back to itself, echo its path, etc.  However,
through the course of working I may rename the file (mynewfile.py); and I'd
like to update this name once within the LyX document and have both the
Program Listing and attachment now point to the right file.

For the two-string approach you suggest, how would I interact with that and
also point it to something else like a program listing, which interprets
string but does not accept ERT?

Thank you,
Joel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: How to Specify PDF Attachments?

[Joel Kulesza]

> On Feb 26, 2020, at 05:51, Jean-Pierre Chrétien  
> wrote:
> 
> Le 26/02/2020 à 07:47, Joel Kulesza a écrit :
>> LyX Developers,
>> Recently, I've been making increased, and good, use of PDF attachments 
>> (e.g., Appendix A of this technical report: 
>> https://www.osti.gov/biblio/1574726).
>> I've achieved this with the `navigator` and `embedfile` packages using ERT.  
>>  `embedfile` is my preferred approach because it interacts better with 
>> `tcolorbox`, has a slightly more simple interface, and has not otherwise 
>> caused problems or shown a deficiency.
>> *Is there a way to achieve this natively in LyX?*  I have not found a way 
>> via menus or Help.  Sorry if I overlooked this.
>> *If this is not currently possible, I want to solicit your thoughts on how 
>> to incorporate such functionality.*  My immediate thought is by using the 
>> Insert -> File -> Child Document dialog with an additional checkbox to 
>> "Attach file to output".  This assumes that the file will be included in the 
>> document in some other fashion.  It is reasonable for someone to merely 
>> attach the file without incorporating it otherwise.  In that case, this 
>> would not be quite right.  Further, I opt for a checkbox rather than another 
>> dropdown entry to minimize the number of times the file must be 
>> browsed/specified (in case it should be listed and attached).
>> I'm curious to hear your thoughts on how to proceed to achieve this 
>> functionality natively in LyX conveniently, intuitively, and while avoiding 
>> duplication of data (i.e., file paths). *Once an approach is identified, 
>> I'll file a ticket in the tracker and will begin coding to that end.*
>> In the meantime, please contact me with any comments, questions, or concerns.
> 
> My personal practice to include pdf docs is to use pdfpages, as it allows to 
> keep the running headers and document page numbering and a lot of tricks.

I don’t just want to include PDFs. I want to include text (or other, sound, 
image, etc.) files, which I don’t want a reader to have to copy-and-paste to 
retrieve. 

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

Re: How to Specify PDF Attachments?

[Joel Kulesza]

> On Feb 26, 2020, at 05:23, Pavel Sanda  wrote:
> 
> On Tue, Feb 25, 2020 at 11:47:40PM -0700, Joel Kulesza wrote:
>> *If this is not currently possible, I want to solicit your thoughts on how
>> to incorporate such functionality.*  My immediate thought is by using the
> 
> I think the most obvious candidate is external material machinery.

This means that I’ll have to specify the file name twice, right?  It is often 
the case that I want/need to list the file but also want to include it for the 
readers convenience. The frustration of files being renamed and having to keep 
them updated in multiple places is why I’m becoming tired of ERT. This, and 
having multiple items for each file (a program listing and the ERT).

I’m not dismissing your suggestion, but just trying to see if we can fulfill my 
goals with it.  Thanks!

Alternatively, perhaps a new external material dialog to act as a file manager, 
which at least will centralize all file names?  If we go this route, I’m 
concerned about keeping the file inclusion local to the context/content that 
refers to it. 

> 
>> I'm curious to hear your thoughts on how to proceed to achieve this
>> functionality natively in LyX conveniently, intuitively, and while avoiding
>> duplication of data (i.e., file paths).  *Once an approach is identified,
>> I'll file a ticket in the tracker and will begin coding to that end.*
>> 
>> In the meantime, please contact me with any comments, questions, or
>> concerns.
> 
> If I don't run adobe acrobat, how I get to the attachment?

Evince can be used and a colleague reports that Okular also works. 

Thanks,
Joel

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

How to Specify PDF Attachments?

[Joel Kulesza]

LyX Developers,

Recently, I've been making increased, and good, use of PDF attachments
(e.g., Appendix A of this technical report:
https://www.osti.gov/biblio/1574726).

I've achieved this with the `navigator` and `embedfile` packages using ERT.
 `embedfile` is my preferred approach because it interacts better with
`tcolorbox`, has a slightly more simple interface, and has not otherwise
caused problems or shown a deficiency.

*Is there a way to achieve this natively in LyX?*  I have not found a way
via menus or Help.  Sorry if I overlooked this.

*If this is not currently possible, I want to solicit your thoughts on how
to incorporate such functionality.*  My immediate thought is by using the
Insert -> File -> Child Document dialog with an additional checkbox to
"Attach file to output".  This assumes that the file will be included in
the document in some other fashion.  It is reasonable for someone to merely
attach the file without incorporating it otherwise.  In that case, this
would not be quite right.  Further, I opt for a checkbox rather than
another dropdown entry to minimize the number of times the file must be
browsed/specified (in case it should be listed and attached).

I'm curious to hear your thoughts on how to proceed to achieve this
functionality natively in LyX conveniently, intuitively, and while avoiding
duplication of data (i.e., file paths).  *Once an approach is identified,
I'll file a ticket in the tracker and will begin coding to that end.*

In the meantime, please contact me with any comments, questions, or
concerns.

Thank you,
Joel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Trivial patch review request

[Joel Kulesza]

On Wed, Aug 14, 2019 at 5:35 PM Scott Kostyshak  wrote:

> On Wed, Aug 14, 2019 at 12:10:46PM -0600, Joel Kulesza wrote:
>
> > Hopefully my activity in the credits
> > isn't seen as too vain.
>
> Not at all. I hope my attempt at humor wasn't what made you think that.
> Whenever I attempt to make a joke I get myself into trouble.


No offense whatsoever.  I had just hoped to submit something simple to be
minimum effort, but having done so incorrectly required outsize effort to
fix.  All in the name of making sure my vanity is preserved, and typo free.

Nevertheless, I appreciate the work that all the development team members
put in (even on these little issues)—it truly makes the writing required
for my work easier and more pleasant than otherwise.

Thanks again,
Joel

Re: Trivial patch review request

[Joel Kulesza]

On Wed, Aug 14, 2019 at 12:10 PM Joel Kulesza  wrote:

> On Wed, Aug 14, 2019 at 11:08 AM Scott Kostyshak  wrote:
>
>> On Wed, Jul 24, 2019 at 09:10:00PM -0600, Joel Kulesza wrote:
>> > LyX Developers,
>> >
>> > Can someone please review/incorporate the attached, trivial, patch,
>> which
>> > corrects a typo in the credits?
>> >
>> > Please let me know if a tracker issue is warranted.
>> >
>> > Otherwise, please contact me with any comments, questions, or concerns.
>>
>> Sorry this took so long, Joel. I don't remember if I missed your message
>> or if I was just feeling lazy.
>>
>> It's in master at 29b725af. CC Riki if you want this to go to stable so
>> that you don't have to wait until 2.4.0 for the SPAM bots to pick up the
>> correction :)
>>
>> Scott
>>
>
> Scott,
>
> Riki took care of this not long after I'd sent it, so I think we're good
> but I appreciate you following up!  Hopefully my activity in the credits
> isn't seen as too vain.
>
> Also, I assume that with your increased activity on the list of late that
> mom, baby, and dad are all doing well?  I hope so!
>
> Thanks again,
> Joel
>

Scott,

Sorry for the quick follow-up, but Riki alerted me offline that the CREDITS
file is generated from generate_contributors.py so this fix (and the others
I see you just made) are needed there.

Sorry for submitting a bogus patch that causes you rework.

- Joel

Re: Trivial patch review request

[Joel Kulesza]

On Wed, Aug 14, 2019 at 11:08 AM Scott Kostyshak  wrote:

> On Wed, Jul 24, 2019 at 09:10:00PM -0600, Joel Kulesza wrote:
> > LyX Developers,
> >
> > Can someone please review/incorporate the attached, trivial, patch, which
> > corrects a typo in the credits?
> >
> > Please let me know if a tracker issue is warranted.
> >
> > Otherwise, please contact me with any comments, questions, or concerns.
>
> Sorry this took so long, Joel. I don't remember if I missed your message
> or if I was just feeling lazy.
>
> It's in master at 29b725af. CC Riki if you want this to go to stable so
> that you don't have to wait until 2.4.0 for the SPAM bots to pick up the
> correction :)
>
> Scott
>

Scott,

Riki took care of this not long after I'd sent it, so I think we're good
but I appreciate you following up!  Hopefully my activity in the credits
isn't seen as too vain.

Also, I assume that with your increased activity on the list of late that
mom, baby, and dad are all doing well?  I hope so!

Thanks again,
Joel

Fwd: #11620: Enhancement Request: Add abbreviated git hash to Insert -> Field -> Other... -> VCI

[Joel Kulesza]

-- Forwarded message -
From: LyX Ticket Tracker 
Date: Sun, Jul 28, 2019 at 7:42 PM
Subject: Re: #11620: Enhancement Request: Add abbreviated git hash to
Insert -> Field -> Other... -> VCI
To: , 
Cc: 


#11620: Enhancement Request: Add abbreviated git hash to Insert -> Field ->
Other... -> VCI
-+
 Reporter:  jkulesza |   Owner:  rikiheck
 Type:  enhancement  |  Status:  fixedinmaster
 Priority:  normal   |   Milestone:  2.4.0
Component:  insets   | Version:  2.4.0dev
 Severity:  normal   |  Resolution:
 Keywords:   |
-+

Comment (by jkulesza):

 Replying to [comment:9 sanda]:
 > And you want to add your new feature into NewInLyX24 of our wiki.

 Happy to, I just didn't want to get ahead of myself in case this isn't
 adopted in 2.4.

This has been incorporated into the master branch.  What is the path to
know if/when it will be incorporated into a forthcoming (2.4) release?  Is
it safe to assume that given the early stage in the 2.4 pre-release process
that it will be?  Or, is there a more formal and/or explicit indication?
Sorry for my ignorance.

Thanks,
Joel

Re: No Longer Tagging Releases?

[Joel Kulesza]

On Sun, Jul 28, 2019 at 12:01 AM Kornel Benko  wrote:

> Am Samstag, 27. Juli 2019, 23:36:09 CEST schrieb Joel Kulesza:
> > Riki, Scott, JMarc, et al.,
> >
> > I'm comparing my work against the 2.3 line of code, and I'm not seeing
> tags
> > for "recent" 2.3.x releases (2.3.1, 2.3.2, 2.3.3).  Was this practice
> > abandoned recently?  Sorry if I missed this discussion on the mailing
> lists.
> >
> > What I see is shown below my signature.
> >
> > Any thoughts you can provide are appreciated.
> >
> > Thanks,
> > Joel
> >
> > I merely see:
> >
> > > git tag
> > ...
> > 2.2.1
> > 2.2.2
> > 2.2.3
> > 2.2.4
> > 2.3.0
> > 2.3.0alpha1
> > 2.3.0alpha1-1
> > 2.3.0beta1
> > 2.3.0rc1
> > 2.3.0rc2
> >
>
> Not here. I see also
> ...
> 2.3.0rc2
> 2.3.1
> 2.3.1-1
> 2.3.2
> 2.3.3
>
> Kornel
>

Thanks for confirming that they *should* have been there.  I thought my
tag-fetch was up to date, but apparently not... I now see them.

Thanks again,
Joel

No Longer Tagging Releases?

[Joel Kulesza]

Riki, Scott, JMarc, et al.,

I'm comparing my work against the 2.3 line of code, and I'm not seeing tags
for "recent" 2.3.x releases (2.3.1, 2.3.2, 2.3.3).  Was this practice
abandoned recently?  Sorry if I missed this discussion on the mailing lists.

What I see is shown below my signature.

Any thoughts you can provide are appreciated.

Thanks,
Joel

I merely see:

> git tag
...
2.2.1
2.2.2
2.2.3
2.2.4
2.3.0
2.3.0alpha1
2.3.0alpha1-1
2.3.0beta1
2.3.0rc1
2.3.0rc2

Trivial patch review request

[Joel Kulesza]

LyX Developers,

Can someone please review/incorporate the attached, trivial, patch, which
corrects a typo in the credits?

Please let me know if a tracker issue is warranted.

Otherwise, please contact me with any comments, questions, or concerns.

Thank you,
Joel


0001-Correct-typo-in-contributor-email-address.patch
Description: Binary data

Re: Insert -> Field Questions / Comments

[Joel Kulesza]

On Mon, Jul 22, 2019 at 3:40 PM Pavel Sanda  wrote:

> On Sun, Jul 14, 2019 at 11:28:28PM -0600, Joel Kulesza wrote:
>
> >2. Can one add/save custom commands for fields?  For example, I want
> to
> >insert an abbreviated git hash (e.g., `git rev-parse --short HEAD`).
> If
> >so, where can I enter this?  Sorry if I missed the right spot in my
> search.
>
> Alternatively I think we would still accept patch for 2.4 with a new custom
> field containing short hash (named like "short revision" or similar).
>

Would a developer please look at the patch attached to
https://www.lyx.org/trac/ticket/11620 and provide feedback such that we can
work toward incorporating this feature into the code base as soon as is
reasonable?

I have also attached screenshots showing how git- and SVN-based documents
appear with the entry (which is valid for git and not for SVN or, AFAIK,
other VCSs).

Thank you,
Joel

Re: Insert -> Field Questions / Comments

[Joel Kulesza]

On Jul 23, 2019, at 10:56, Richard Kimberly Heck  wrote:
> 
>> On 7/23/19 10:52 AM, Joel Kulesza wrote:
>> 
>> 
>>> On Mon, Jul 22, 2019 at 9:17 PM Richard Kimberly Heck  
>>> wrote:
>>> On 7/22/19 5:12 PM, Pavel Sanda wrote:
>>> > On Sun, Jul 14, 2019 at 11:28:28PM -0600, Joel Kulesza wrote:
>>> >> LyX Developers (Jürgen in particular):
>>> >>
>>> >> A few questions on the Insert -> Field capability with respect to version
>>> >> control:
>>> >>
>>> >>1. When git hashes (i.e. VCS Revisions) are entered, I see that they 
>>> >> are
>>> >>updated when the underlying revision is updated.  This generally 
>>> >> delights
>>> >>me.  However, what governs this update logic timing (when the 
>>> >> document is
>>> >>opened, at some interval, etc.)?  Is there an indication to the user 
>>> >> that
>>> >>this part of the document has changed?  If not, should there be?
>>> > Without looking at the code IIRC it updates at each document (re)load 
>>> > (that
>>> > includes git commits via lyx gui).
>>> 
>>> I could be wrong, but it looks to be re-calculated each time through
>>> updateBuffer (which would include reloads). Which, Joel, would mean it
>>> is reset very often. Not on every keystroke, but almost that often.
>>> 
>>> The user should just expect these auto-calculated things to update, uh,
>>> automatically, it seems to me.
>> 
>> That is good news for my purpose.  Further, do we know if it is recalculated 
>> when rendered to PDF via command line? I hope so and will test later unless 
>> someone knows for sure...
> Sorry, Pavel is right in his other message: This only gets re-calculated when 
> the document is reloaded, at least for git. I did not dig deeply enough into 
> the code to see where it is cached. So, in that sense, the inset reports the 
> revision on which the document is based. If the file on disk were changed 
> externally, then I think you'd get a warning about that, and ask you to 
> reload, or whatever.
> 
> In any event, this is calculated, fresh, if the document is exported via the 
> command line.
> 
> Riki
> 

Riki, thanks for confirming Pavel’s note. The behavior you describe is just 
what I’m looking for!

Thanks again,
Joel

Re: Insert -> Field Questions / Comments

[Joel Kulesza]

On Mon, Jul 22, 2019 at 9:17 PM Richard Kimberly Heck 
wrote:

> On 7/22/19 5:12 PM, Pavel Sanda wrote:
> > On Sun, Jul 14, 2019 at 11:28:28PM -0600, Joel Kulesza wrote:
> >> LyX Developers (Jürgen in particular):
> >>
> >> A few questions on the Insert -> Field capability with respect to
> version
> >> control:
> >>
> >>1. When git hashes (i.e. VCS Revisions) are entered, I see that they
> are
> >>updated when the underlying revision is updated.  This generally
> delights
> >>me.  However, what governs this update logic timing (when the
> document is
> >>opened, at some interval, etc.)?  Is there an indication to the user
> that
> >>this part of the document has changed?  If not, should there be?
> > Without looking at the code IIRC it updates at each document (re)load
> (that
> > includes git commits via lyx gui).
>
> I could be wrong, but it looks to be re-calculated each time through
> updateBuffer (which would include reloads). Which, Joel, would mean it
> is reset very often. Not on every keystroke, but almost that often.
>
> The user should just expect these auto-calculated things to update, uh,
> automatically, it seems to me.
>

That is good news for my purpose.  Further, do we know if it is
recalculated when rendered to PDF via command line? I hope so and will test
later unless someone knows for sure...

To Pavel's remark regarding a patch with the revised commit for 2.4, I'll
try to put one together when I return home from travel.  I will also
describe the steps I took in my originally attached screenshot that gave
the unexpected error message.

Thank you,
Joel

Re: Insert -> Field Questions / Comments

[Joel Kulesza]

On Sun, Jul 14, 2019 at 11:44 PM Jürgen Spitzmüller  wrote:

> Am Sonntag, den 14.07.2019, 23:28 -0600 schrieb Joel Kulesza:
> > LyX Developers (Jürgen in particular):
>
> Passing these to Pavel. I know nect to nothing about these particular
> types of info insets.
>

Pavel,

Do you have any thoughts on my original inquiry?  Your response will be
non-trivial factors in a decision to adopt LyX for a project I'm
collaborating on.

Thank you,
Joel

P.S. Sorry for the misattribution, I'd thought Jürgen was a driving force
behind the entirety of this capability.

Re: [LyX/master] Respect OS-level keyboard language

[Joel Kulesza]

On Sat, Jul 20, 2019 at 8:11 AM Jürgen Spitzmüller  wrote:

> Am Samstag, den 20.07.2019, 15:40 +0200 schrieb Jean-Marc Lasgouttes:
> > > As to the flag icon idea, I have to say (with my sociolinguist hat
> > > on)
> > > that I am not particularly thrilled by the underpinning association
> > > of
> > > languages with countries/nations.
> >
> > Indicate language in status bar and add a menu there?
>
> How is this easier to access than the context menu?
>

It is visible.  I've run into several users who didn't think to look in the
context menu for some behavior they wanted.  One must be judicious so the
status bar doesn't fill up with extraneous items; however, at times when
this issue does apply the status bar seems reasonable to me.  It's a break
with the general UI design trend; however, in this case, the approach seems
reasonable to me.

Re: Towards LyX 2.4.0alpha1?

[Joel Kulesza]

On Jul 14, 2019, at 01:49, Stephan Witt  wrote:
> 
>> Am 13.07.2019 um 21:13 schrieb Jean-Marc Lasgouttes :
>> 
>> 3/ The following files need to be updated:
>> INSTALL.cmake (Kornel?),
>> INSTALL.MacOSX (Stephan?), should it be renamed INSTALL.macOS?
> 
> I had promised to review it. So, I’ll do it next weeks. 
> Yes, it should be renamed, this is the official name since 2016.

If you’d like a review of your review, please let me know. In addition, if 
you’re interested in any suggestions, please let me know. 

Thank you,
Joel

GPG Key Retrieval Instructions on Website

[Joel Kulesza]

LyX Developers,

For those not familiar with GPG signing and verification, the section on
the website Download page (https://www.lyx.org/Download) could benefit from
some additional instructions.  For example, if one naively runs the command
given, they may receive:

> gpg --recv-keys FE66471B43559707AFDAD955DE7A44FAC7FB382D
gpg: no keyserver known (use option --keyserver)
gpg: keyserver receive failed: Syntax error in URI

It may be good to show the command sequence to set this up to avoid such an
issue.

Thanks,
Joel

Re: A baby example prototype widget that mixes Jupyter and LyX

[Joel Kulesza]

Jason,

No, I've not tried those.  However, I feel like we have solutions looking
for a problem.  What I'm asking is: what problem(s) are you trying to solve?

I'm unsure what I'm looking for in terms of an ideal mixture of LyX and
Jupyter, because I'm generally happy with the way things work now.

If anything, I'd like to have evaluatable, and collapsable, Python fields
in LyX kind of like code blocks in Mathematica notebooks.  However, I'm
still unsure how I would incorporate something like that into an actual LyX
document other than to have generated matplotlib figures.  I also suspect
other developers would have concerns about arbitrary code execution
following this approach.  Bottom line: I'd prefer not to have two separate
documents to manage but rather have the two integrated into one.

Thanks,
Joel

P.S. I switched to top-posting to try to maintain consistency with you so
the thread doesn't become too chaotic.

On Sun, Jul 7, 2019 at 9:13 PM Jason Sun  wrote:

> Have you tried knitr and reticulate? I can build an isomorphism between
> the embedded browser and LyX. Maybe we could do this in another way. Could
> you tell me what do you expect to see in an ideal mixture of Jupyter and
> LyX?
>
> Sent from my iPhone
>
> On Jul 7, 2019, at 10:46 PM, Joel Kulesza  wrote:
>
> On Sat, Jul 6, 2019 at 2:03 PM Jason Sun  wrote:
>
>> The proper way to establish communication is to use ZeroMQ to interact
>> with IPython directly from LyX.  I read the jupyter docs, it is something
>> we could try to do. I can communicate with the LyX main  buffer now by
>> letting the main Browser to as ccess LyX.h, and thus have access to call
>> dispatch, and do the injection of variables. It does seem a bit naive
>> compared to the zeroMQ approach. But I would argue that it might be
>> sufficient for light uses. OTOH, if webengine is used, we should utilize
>> its full potential and design the communication framework properly.
>>
>> To answer some of other question: yes, this widget is dockable in either
>> 4 positions. It also could be dragged out as a single page view.
>>
>> I need to try see how hard it is to embed the zeroMQ communication layer.
>> It can be done for sure, the question is if it is worth the effort or do we
>> have some better alternatives.
>>
>> Sent from my iPhone
>>
>> On Jul 6, 2019, at 9:12 AM, Joel Kulesza  wrote:
>>
>> On Tue, Jul 2, 2019 at 11:03 AM Jason Sun  wrote:
>>
>>> I have built an example prototype widget that tries to combine LyX and
>>> Jupyter Notebook together.
>>>
>>> Is it implemented via QtWebEngine. Basically, by embedding a mini
>>> webpage browser inside LyX.
>>>
>>> A screenshot is here:
>>> https://github.com/jupyter/notebook/issues/1604#issuecomment-507746234
>>>
>>> A bidirectional communication between LyX and Jupyter Notebook could be
>>> implemented via this browser. With the help of jupyter lab, we can get
>>> cross platform terminal for free.
>>>
>>> Would this be something worth further pursuing down the road?
>>>
>>> Using Web, a lot could be implemented. Especially, Qt 5.13 introduces
>>> Web Assembly. With the help of that, LyX could have it OverLeaf counter
>>> part with stronger abilities!
>>>
>>
>> Jason,
>>
>> Thanks for your thoughts and work on this.  Sorry I've been quiet to this
>> point, but I hoped to ask a few questions as I think about how I'd use your
>> work.
>>
>> I'm a rather avid LyX user, and routinely use Jupyter notebooks.
>> However, I'm still not entirely clear how these two will be integrated.  I
>> see the screenshot you provided on GitHub; however, it still seems like the
>> LyX document and notebook are quite separate.  It's not clear to me what is
>> gained by putting them both within one window.  Can you please help me
>> understand how you foresee a user interacting with these two?
>>
>> Some more pointed questions based on the interface you provided in the
>> screenshot:
>>
>>1. I assume the browser component can be moved to be bottom half
>>rather than right half.  Is that correct?  I usually run LyX on half my
>>monitor, so I'd be reluctant to end up only running it in 1/4 (and Jupyter
>>in the other 1/4).
>>2. Do you have a way to integrate Jupyter I/O with the LyX document?
>>For example, as a Python variable gets updated in an evaluation it will
>>then get captured the next time the LyX-produced PDF is compiled/viewed.
>>3. Will your .ipynb be included in the File -> Export -> LyX Archive?
>>
>>
>

Re: A baby example prototype widget that mixes Jupyter and LyX

[Joel Kulesza]

On Sat, Jul 6, 2019 at 2:03 PM Jason Sun  wrote:

> The proper way to establish communication is to use ZeroMQ to interact
> with IPython directly from LyX.  I read the jupyter docs, it is something
> we could try to do. I can communicate with the LyX main  buffer now by
> letting the main Browser to as ccess LyX.h, and thus have access to call
> dispatch, and do the injection of variables. It does seem a bit naive
> compared to the zeroMQ approach. But I would argue that it might be
> sufficient for light uses. OTOH, if webengine is used, we should utilize
> its full potential and design the communication framework properly.
>
> To answer some of other question: yes, this widget is dockable in either 4
> positions. It also could be dragged out as a single page view.
>
> I need to try see how hard it is to embed the zeroMQ communication layer.
> It can be done for sure, the question is if it is worth the effort or do we
> have some better alternatives.
>
> Sent from my iPhone
>
> On Jul 6, 2019, at 9:12 AM, Joel Kulesza  wrote:
>
> On Tue, Jul 2, 2019 at 11:03 AM Jason Sun  wrote:
>
>> I have built an example prototype widget that tries to combine LyX and
>> Jupyter Notebook together.
>>
>> Is it implemented via QtWebEngine. Basically, by embedding a mini webpage
>> browser inside LyX.
>>
>> A screenshot is here:
>> https://github.com/jupyter/notebook/issues/1604#issuecomment-507746234
>>
>> A bidirectional communication between LyX and Jupyter Notebook could be
>> implemented via this browser. With the help of jupyter lab, we can get
>> cross platform terminal for free.
>>
>> Would this be something worth further pursuing down the road?
>>
>> Using Web, a lot could be implemented. Especially, Qt 5.13 introduces Web
>> Assembly. With the help of that, LyX could have it OverLeaf counter part
>> with stronger abilities!
>>
>
> Jason,
>
> Thanks for your thoughts and work on this.  Sorry I've been quiet to this
> point, but I hoped to ask a few questions as I think about how I'd use your
> work.
>
> I'm a rather avid LyX user, and routinely use Jupyter notebooks.  However,
> I'm still not entirely clear how these two will be integrated.  I see the
> screenshot you provided on GitHub; however, it still seems like the LyX
> document and notebook are quite separate.  It's not clear to me what is
> gained by putting them both within one window.  Can you please help me
> understand how you foresee a user interacting with these two?
>
> Some more pointed questions based on the interface you provided in the
> screenshot:
>
>1. I assume the browser component can be moved to be bottom half
>rather than right half.  Is that correct?  I usually run LyX on half my
>monitor, so I'd be reluctant to end up only running it in 1/4 (and Jupyter
>in the other 1/4).
>2. Do you have a way to integrate Jupyter I/O with the LyX document?
>For example, as a Python variable gets updated in an evaluation it will
>then get captured the next time the LyX-produced PDF is compiled/viewed.
>3. Will your .ipynb be included in the File -> Export -> LyX Archive?
>
> Thanks again,
> Joel
>
>
Jason,

Thanks for your thoughts.  However, my one main question still seems
unanswered: how you foresee a user interacting with these two applications
(LyX and Jupyter)?

What is the workflow that you're imagining versus how it currently would
be: with LyX and a web browser open separately?  What advantage is gained
through the coupling of the two applications?  For example, are you working
toward a LyX document with Jupyter-driven evaluated Python cells?  Or,
perhaps a Jupyter notebook that will generate a LyX document?  Perhaps
something else?

Thanks,
Joel

Re: A baby example prototype widget that mixes Jupyter and LyX

[Joel Kulesza]

On Tue, Jul 2, 2019 at 11:03 AM Jason Sun  wrote:

> I have built an example prototype widget that tries to combine LyX and
> Jupyter Notebook together.
>
> Is it implemented via QtWebEngine. Basically, by embedding a mini webpage
> browser inside LyX.
>
> A screenshot is here:
> https://github.com/jupyter/notebook/issues/1604#issuecomment-507746234
>
> A bidirectional communication between LyX and Jupyter Notebook could be
> implemented via this browser. With the help of jupyter lab, we can get
> cross platform terminal for free.
>
> Would this be something worth further pursuing down the road?
>
> Using Web, a lot could be implemented. Especially, Qt 5.13 introduces Web
> Assembly. With the help of that, LyX could have it OverLeaf counter part
> with stronger abilities!
>

Jason,

Thanks for your thoughts and work on this.  Sorry I've been quiet to this
point, but I hoped to ask a few questions as I think about how I'd use your
work.

I'm a rather avid LyX user, and routinely use Jupyter notebooks.  However,
I'm still not entirely clear how these two will be integrated.  I see the
screenshot you provided on GitHub; however, it still seems like the LyX
document and notebook are quite separate.  It's not clear to me what is
gained by putting them both within one window.  Can you please help me
understand how you foresee a user interacting with these two?

Some more pointed questions based on the interface you provided in the
screenshot:

   1. I assume the browser component can be moved to be bottom half rather
   than right half.  Is that correct?  I usually run LyX on half my monitor,
   so I'd be reluctant to end up only running it in 1/4 (and Jupyter in the
   other 1/4).
   2. Do you have a way to integrate Jupyter I/O with the LyX document?
   For example, as a Python variable gets updated in an evaluation it will
   then get captured the next time the LyX-produced PDF is compiled/viewed.
   3. Will your .ipynb be included in the File -> Export -> LyX Archive?

Thanks again,
Joel

Re: Discussion on a few ideas.

[Joel Kulesza]

On Tue, Jul 2, 2019 at 2:14 PM Jason Sun  wrote:

> Comment: I am replying to Joel's message.
>
> Hi Joel. Thanks for your response. I have no idea the thread is in a mess.
> I replied to my previous messages by hitting the reply button on the lyx
> mail archive. It automatically jumped to my Gmail. Also weirdly, sometimes
> I get reply notification in my Gmail sometimes I don't. Of all the
> communications in the thread, this is the only one that I was notified by
> Gmail.
>
> Is this correspondence in correct format?
>
>
Jason,

Yes, this was properly formatted into a thread and maintained my comments,
thanks!

I'll note that you top-posted (Gmail's default behavior).  I don't have a
strong preference either way, but others on this list prefer bottom-posting
so that the reply follows the text being replied to.  This takes some extra
work in GMail, but can be done (as I've done here).

Thanks!

Joel

Re: Discussion on a few ideas.

[Joel Kulesza]

On Tue, Jul 2, 2019 at 9:23 AM Jason Sun  wrote:

> Okay. I will then build up a prototype then. It is basically a jupyter
> notebook pane.
>

Jason,

Please include comments that you are replying to and either top post or
bottom post (this forum's preference, as I've done here).  That way there
is context for your comments.  It is *very* hard to follow the conversation
otherwise.  Also, the way GMail is organizing your replies, they are all
separate threads.  I wonder if others are seeing this... This is the first
time I've observed this behavior on the mailing list and my email client,
which is what causes me to comment now.

I have thoughts that I'd like to contribute to your work, but without a
unified discussion thread it is very hard to find where best to provide my
input.

Thank you,
Joel

Re: [Patch] Re: How to signal missing citation

[Joel Kulesza]

On Thu, Jun 6, 2019 at 5:56 PM Pavel Sanda  wrote:

> On Thu, Jun 06, 2019 at 03:42:05PM +0200, Pavel Sanda wrote:
> > Looks little bit difficult within the current machinery (if I understand
> > it correctly). Cits can be fixed by incremental runs and we see that in
> > updated result value of scanres of LaTeX::run, i.e. if fixed it does not
> > contain UNDEF_CIT anymore.
> > The accompanying structure of errors "terr" does not get reset, so once
> > you push there some info about missing citation it's not going away.
> > At the end if you by re-runing fix citation problem but there still
> remain
> > some other problem user will wrongly see it within the list of errors...
> >
> > I actually do not understand why not reseting "ter" before each run.
> > Seems reasonable to me, but it's hard to test without having examples
> > which produced all the trickery in the code.
> > Otherwise we could just grep in scanLog for the label/citation name
> > and push it to the error dialog.
>
> Ok this is result of todays hacking, ref/cits will get proper information
> in error dialog as well.
>

Excellent, thanks!


> Many citations won't make it because pdflatex splits line at 80 chars
> and line-based parsing will fail.
>

Understood.  Something is better than nothing though.


> I tested plain bibtex & natbib, I don't use the other engines so have
> very little clue what happens there.
>

I will test the same when this makes it to master.

Re: [Patch] Re: How to signal missing citation

[Joel Kulesza]

On Thu, Jun 6, 2019 at 11:43 AM Pavel Sanda  wrote:

> On Wed, Jun 05, 2019 at 07:50:55PM -0600, Joel Kulesza wrote:
> > Thanks for putting these together so quickly.  Some comments:
> >
> >1.  p1: The notation seems inconsistent, referring to both citations
> and
> >references.  From what I understand, I would refer strictly to
> citations
> >(perhaps preceded by bibliography, to help orient a reader).
>
> I tried to disentangle little bit, see below.
>
> >2. p1: I believe that when a citation key cannot be found, the key is
> >given.  Could this be provided to the user to help him/her better
> locate
> >the issue?
>
> Looks little bit difficult within the current machinery (if I understand
> it correctly). Cits can be fixed by incremental runs and we see that in
> updated result value of scanres of LaTeX::run, i.e. if fixed it does not
> contain UNDEF_CIT anymore.
> The accompanying structure of errors "terr" does not get reset, so once
> you push there some info about missing citation it's not going away.
> At the end if you by re-runing fix citation problem but there still remain
> some other problem user will wrongly see it within the list of errors...
>
> I actually do not understand why not reseting "ter" before each run.
> Seems reasonable to me, but it's hard to test without having examples
> which produced all the trickery in the code.
> Otherwise we could just grep in scanLog for the label/citation name
> and push it to the error dialog.
>
> >3. p2: Perhaps "undefined cross-references"?  Same comment about
> echoing
> >the key that is incorrectly cross-referenced?
>
> We are getting this error from LaTeX and it says "reference" in both cases
> when cit or cross-ref is missing (and maybe in some different cases I do
> not
> know yet). So I kept it intentionally vague, I changed what we grep for so
> it's
> hopefully better now.
>

I understand.


>
> > To your concern about being too aggressive: this is potentially an issue.
> > However, while I find it a nuisance when I insert a bibliography, haven't
> > yet inserted citations, and have to dismiss the errors and "show
> anyway," I
> > prefer that situation to silent failures that I *don't* expect.  The same
> > applies here.
>
> Why I am not particularly confident about the reference part is that some
> packages like hyperref might be doing some business with references in
> backgrounds (for building ToC or similar) and would flush similar warnings
> which are actually harmless in final pdf -- but we will bombard users with
> error dialog all the time.
> We can try to push to master and wait how much will people scream...
>

If when this is pushed, I'll try to pull and compile some documents that I
suspect will act as good tests.  I'm reluctant to now with the patch as
it's evolving.


>
> > Do you have any thoughts on coloring the buttons in the GUI to indicate
> > breakage?
>
> Not enough visibile IMHO, and our current approach seem to be good enough.
>

Alone, I agree.  However, I'd like to see this as a way to help someone
track down which citation is a problem as they're working with the
document.

Re: [Patch] Re: How to signal missing citation

[Joel Kulesza]

On Wed, Jun 5, 2019 at 8:47 AM Pavel Sanda  wrote:

> On Tue, Jun 04, 2019 at 01:51:08PM -0600, Joel Kulesza wrote:
> > I also think a ???show anyway??? error on view is warranted for broken
> citations, similar to when no citations are entered.
>
> Me too and this should be enough actually.
> - Patch 1 will err when citation is broken
> - adding patch 2 on top of that will also err in case cross-ref is broken.
>
> This is potentially going to affect users who live at ease with broken
> refs,
> so please object if you think I am going too far.
>
> I think we should stop if cits are broken, I am less sure about references
> broken.
> If there are no objections even to references I improve 2nd patch little
> bit so
> UNDEF_REF instead of UNDEF_CIT is used and commit it too.
>

Thanks for putting these together so quickly.  Some comments:

   1.  p1: The notation seems inconsistent, referring to both citations and
   references.  From what I understand, I would refer strictly to citations
   (perhaps preceded by bibliography, to help orient a reader).
   2. p1: I believe that when a citation key cannot be found, the key is
   given.  Could this be provided to the user to help him/her better locate
   the issue?
   3. p2: Perhaps "undefined cross-references"?  Same comment about echoing
   the key that is incorrectly cross-referenced?

To your concern about being too aggressive: this is potentially an issue.
However, while I find it a nuisance when I insert a bibliography, haven't
yet inserted citations, and have to dismiss the errors and "show anyway," I
prefer that situation to silent failures that I *don't* expect.  The same
applies here.

Do you have any thoughts on coloring the buttons in the GUI to indicate
breakage?

I looked at this somewhat briefly a while back but I couldn't figure it out
in the time that I looked.  I suspect the correct approach is obvious to
someone more familiar with the code, but I'm not sure who that would be
(I'd be willing to look at this again if someone is willing to provide some
guidance).

Thanks again,
Joel

Re: How to signal missing citation

[Joel Kulesza]

> On Jun 4, 2019, at 07:37, Pavel Sanda  wrote:
> 
> Hi,
> 
> could we make missing citation warning somehow more visible
> when they happen? We detect them from the log already,
> but we just color them in latex output window.
> 
> I would like to have something more disturbing -
> e.g. red exlamation mark in status line (or better idea?).
> 
> We actually don't need even the latex run, the citation
> inset already shows ?? in case something went south,
> so we could use that info.
> 
> Opinions?
> 
> Pavel

I would love to see a differently colored cross-reference and citation button 
for when such entries are broken.

I also think a “show anyway” error on view is warranted for broken citations, 
similar to when no citations are entered. 

Thanks,
Joel

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

[Joel Kulesza]

On Thu, May 30, 2019 at 6:36 PM Richard Kimberly Heck 
wrote:

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

Thank you.  This is a minor annoyance I've also coped with for some time.
I'm happy to hear that it's been resolved.

Thanks again,
Joel