Re: [patch] Selection stats in statusbar

2022-08-09 Thread Pavel Sanda
On Sat, Aug 06, 2022 at 12:23:25PM -0400, Scott Kostyshak wrote:
> > I suggest we put this into master and let ppl test on their machines
> > if any noticeable changes are visible when editing documents. At worst
> > we can disable this feature by default.
> 
> Sounds good to me. Thanks for the patch updates. I suggest to commit now.

It's now in 5b50a97fd76d2.

Please give it some testing once you back...

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


Re: [patch] Selection stats in statusbar

2022-08-04 Thread Pavel Sanda
On Sun, Jul 31, 2022 at 07:29:35AM -0400, Scott Kostyshak wrote:
> On Sun, Jul 31, 2022 at 11:34:25AM +0200, Pavel Sanda wrote:
> > On Sun, Jul 31, 2022 at 05:16:17AM -0400, Scott Kostyshak wrote:
> > > I'm on vacation and won't be able to test for a few weeks. Can you do
> > > the test I described before? Just select a big document, and then hold
> > > Shift +  to decrease the selection towards the beginning of the
> > > document. I just counted using a wrist stopwatch and compared
> > > with/without the patch.
> > 
> > I did that already and haven't seen noticeable lag. But I might have too 
> > powerful machine, that's why I ask. Anyway, increasing delay would be
> > trivial change later.
> That's good enough for me. 0.5 seems fine to me and I imagine it could

Attached is a newer version. Actually something like 4th rewrite - I figured
that even the combination of mid-sized document and very fast keyboard repeat
rates has already visible interference from stats computation.

I ended with more conservative approach - stats updates have now 5s sampling
rate and I think that's totally fine for casual statusbar look how your 
document is doing.

The only situation when sampling rate get's back 0.5s is when small
piece (<5000 chars) of text is being selected -  that's when you need
instant visual feedback (and it's the initial motivation for this whole
patch).

I suggest we put this into master and let ppl test on their machines
if any noticeable changes are visible when editing documents. At worst
we can disable this feature by default.

Pavel
diff --git a/lib/ui/stdcontext.inc b/lib/ui/stdcontext.inc
index bd94e7c904..8c79c5f351 100644
--- a/lib/ui/stdcontext.inc
+++ b/lib/ui/stdcontext.inc
@@ -731,6 +731,8 @@ Menuset
Separator
Item "Show Zoom Level|Z" "ui-toggle zoomlevel"
Item "Show Zoom Slider|S" "ui-toggle zoomslider"
+   Separator
+   Item "Show Document Statistics|D" "ui-toggle statistics"
End
 
 End
diff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index 992b47a441..ae8245d070 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -4097,6 +4097,7 @@ void LyXAction::init()
frame  : Toggle visibility of the frames around editing 
window.\n
zoomslider : Toggle visibility of the zoom slider in 
statusbar.\n
zoomlevel  : Toggle visibility of the zoom level display in 
statusbar.\n
+   statistics : Toggle visibility of the document statistics count 
in statusbar.\n
fullscreen : Toggle fullscreen mode. This also covers calling 
the
 previous functions. However #LFUN_TOOLBAR_TOGGLE 
for the
 custom tweaks of the toolbars should be used.
diff --git a/src/frontends/qt/GuiView.cpp b/src/frontends/qt/GuiView.cpp
index 8f6bf07115..fd738e100e 100644
--- a/src/frontends/qt/GuiView.cpp
+++ b/src/frontends/qt/GuiView.cpp
@@ -523,6 +523,7 @@ public:
 
///
QTimer statusbar_timer_;
+   QTimer statusbar_stats_timer_;
/// auto-saving of buffers
Timeout autosave_timeout_;
 
@@ -546,6 +547,18 @@ public:
 
/// flag against a race condition due to multiclicks, see bug #1119
bool in_show_;
+
+   // Timers for statistic updates in buffer
+   /// Current time left to the nearest info update
+   int time_to_update = 1000;
+   ///Basic step for timer in ms. Basically reaction time for short 
selections
+   int const timer_rate = 500;
+   /// Real stats updates infrequently. First they take long time for big 
buffers, second
+   /// they are visible for fast-repeat keyboards even for mid documents.
+   int const default_stats_rate = 5000;
+   /// Detection of new selection, so we can react fast
+   bool already_in_selection_ = false;
+
 };
 
 QSet GuiView::GuiViewPrivate::busyBuffers;
@@ -553,8 +566,8 @@ QSet GuiView::GuiViewPrivate::busyBuffers;
 
 GuiView::GuiView(int id)
: d(*new GuiViewPrivate(this)), id_(id), closing_(false), busy_(0),
- command_execute_(false), minibuffer_focus_(false), 
toolbarsMovable_(true),
- devel_mode_(false)
+ command_execute_(false), minibuffer_focus_(false), 
stat_counts_enabled_(true),
+ toolbarsMovable_(true), devel_mode_(false)
 {
connect(this, SIGNAL(bufferViewChanged()),
this, SLOT(onBufferViewChanged()));
@@ -582,6 +595,9 @@ GuiView::GuiView(int id)
}
connect(_timer_, SIGNAL(timeout()),
this, SLOT(clearMessage()));
+   connect(_stats_timer_, SIGNAL(timeout()),
+   this, SLOT(showStats()));
+   d.statusbar_stats_timer_.start(d.timer_rate);
 
// We don't want to keep the window in memory if it is closed.
setAttr

Re: lyx 2.4.0 dev -download

2022-08-03 Thread Pavel Sanda
On Wed, Aug 03, 2022 at 08:24:38PM +0200, Pavel Sanda wrote:
> On Wed, Aug 03, 2022 at 10:24:31AM +0100, José Matos wrote:
> > Is there are any script take takes the repository and outputs a source
> > release (like a tar ball gzip or xz)?
> 
> make dist

wait weren't you release manager for 1.5/6 ??? :)

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


Re: lyx 2.4.0 dev -download

2022-08-03 Thread Pavel Sanda
On Wed, Aug 03, 2022 at 10:24:31AM +0100, José Matos wrote:
> Is there are any script take takes the repository and outputs a source
> release (like a tar ball gzip or xz)?

make dist

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


Re: approve link in wiki

2022-08-03 Thread Pavel Sanda
On Wed, Aug 03, 2022 at 12:23:14PM +0200, Cor Blom wrote:
> Can someone approve the link?

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


Re: Wrong commit ?

2022-08-02 Thread Pavel Sanda
On Mon, Aug 01, 2022 at 06:18:53PM +0200, Jean-Pierre Chrétien wrote:
> >>$ git log
> >>commit 4c72d8aeac01c53e27732999108f249356e67c5c (HEAD -> master, 
> >>origin/master,
> >>origin/HEAD)

...

> What bugs me is the  (HEAD -> master, origin/master, origin/HEAD) part,
> which is not present usually.

It is present for me all the time. Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Interesting discovery from automatic tools (python code)

2022-07-31 Thread Pavel Sanda
On Sun, Jul 31, 2022 at 11:41:02AM +0100, José Matos wrote:
> Please test it.

Will take little time, hopefully tomorrow. P
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Interesting discovery from automatic tools (python code)

2022-07-31 Thread Pavel Sanda
On Sun, Jul 31, 2022 at 06:37:29PM +0100, José Matos wrote:
> On Sun, 2022-07-31 at 11:16 +0200, Pavel Sanda wrote:
> > On Sun, Jul 31, 2022 at 07:15:29AM +0100, José Matos wrote:
> > > Now in the context of the pyupgrade fixes this is applied to top
> > > /lib
> > > scripts. I need this before working on configure.py.
> > 
> > Sure, whatever you need :)
> > The patch is in.
> > 
> > Pavel
> 
> Third iteration now regarding the python files in lib/scripts. Solves
> the same issues identified before.

It's in. Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [patch] Selection stats in statusbar

2022-07-31 Thread Pavel Sanda
On Sun, Jul 31, 2022 at 05:16:17AM -0400, Scott Kostyshak wrote:
> I'm on vacation and won't be able to test for a few weeks. Can you do
> the test I described before? Just select a big document, and then hold
> Shift +  to decrease the selection towards the beginning of the
> document. I just counted using a wrist stopwatch and compared
> with/without the patch.

I did that already and haven't seen noticeable lag. But I might have too 
powerful machine, that's why I ask. Anyway, increasing delay would be
trivial change later.

> I did not look, but will this be on by default? Would you object to a
> way to turn off the stats, like we have a way to turn off the zoom level
> and slider in the status bar?

Already done. You can disable it in the same way you can disappear zoom slider.

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


Re: Interesting discovery from automatic tools (python code)

2022-07-31 Thread Pavel Sanda
On Sun, Jul 31, 2022 at 07:15:29AM +0100, José Matos wrote:
> Now in the context of the pyupgrade fixes this is applied to top /lib
> scripts. I need this before working on configure.py.

Sure, whatever you need :)
The patch is in.

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


Re: Interesting discovery from automatic tools (python code)

2022-07-30 Thread Pavel Sanda
On Sat, Jul 30, 2022 at 05:49:05PM +0100, José Matos wrote:
> In any case the code after this patch is more correct, and that is
> always a good thing.

Good. This one applies, so it's in now.
Now that I have you on hotline, any chance to have a look at the
configure patch we discussed in March? :)
(Was: LyX 2.4.0 (IM policy.xml ban on eps/pdf conversions))

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


Re: [patch] Selection stats in statusbar

2022-07-30 Thread Pavel Sanda
On Fri, Jul 15, 2022 at 12:05:25AM +0200, Pavel Sanda wrote:
> On Thu, Jul 14, 2022 at 09:31:06AM +0200, Daniel wrote:
> > >The drawback is that's it's difficult to understand the interaction between
> > >the two timers now. I stared on the code for couple minutes and it was
> > >not clear to me what is the idea behind your stop/start changes.
> > 
> > Some comments would probably have been good. I could try to add them if
> > there is interest.
> 
> If I find little time I'll try the QTimer route and see whether we converge :)

So I tried to find the best from solution from both worlds.
In the attached patch we use QTimer (0.5s between updates) for updating stats.
To avoid tricky interactions with another timer and current messages in
status bar I simply cretaed completely new label next to the slider, so it's
independent mechanism with no interactions.

On top of that its possible to disable the visibility via context menu, but it's
part of session not new RC variable, which seems good enough compromise.

The update interval is now 0.5s, let me know if there is any slugishness
in your testing. I didn't see any, but I can easliy increase to 1s if need be.

Any objections now?

Pavel
diff --git a/lib/ui/stdcontext.inc b/lib/ui/stdcontext.inc
index bd94e7c904..8c79c5f351 100644
--- a/lib/ui/stdcontext.inc
+++ b/lib/ui/stdcontext.inc
@@ -731,6 +731,8 @@ Menuset
Separator
Item "Show Zoom Level|Z" "ui-toggle zoomlevel"
Item "Show Zoom Slider|S" "ui-toggle zoomslider"
+   Separator
+   Item "Show Document Statistics|D" "ui-toggle statistics"
End
 
 End
diff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index 992b47a441..ae8245d070 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -4097,6 +4097,7 @@ void LyXAction::init()
frame  : Toggle visibility of the frames around editing 
window.\n
zoomslider : Toggle visibility of the zoom slider in 
statusbar.\n
zoomlevel  : Toggle visibility of the zoom level display in 
statusbar.\n
+   statistics : Toggle visibility of the document statistics count 
in statusbar.\n
fullscreen : Toggle fullscreen mode. This also covers calling 
the
 previous functions. However #LFUN_TOOLBAR_TOGGLE 
for the
 custom tweaks of the toolbars should be used.
diff --git a/src/frontends/qt/GuiView.cpp b/src/frontends/qt/GuiView.cpp
index 8f6bf07115..c381d547b5 100644
--- a/src/frontends/qt/GuiView.cpp
+++ b/src/frontends/qt/GuiView.cpp
@@ -523,6 +523,7 @@ public:
 
///
QTimer statusbar_timer_;
+   QTimer statusbar_stats_timer_;
/// auto-saving of buffers
Timeout autosave_timeout_;
 
@@ -553,8 +554,8 @@ QSet GuiView::GuiViewPrivate::busyBuffers;
 
 GuiView::GuiView(int id)
: d(*new GuiViewPrivate(this)), id_(id), closing_(false), busy_(0),
- command_execute_(false), minibuffer_focus_(false), 
toolbarsMovable_(true),
- devel_mode_(false)
+ command_execute_(false), minibuffer_focus_(false), 
stat_counts_enabled_(true),
+ toolbarsMovable_(true), devel_mode_(false)
 {
connect(this, SIGNAL(bufferViewChanged()),
this, SLOT(onBufferViewChanged()));
@@ -582,6 +583,9 @@ GuiView::GuiView(int id)
}
connect(_timer_, SIGNAL(timeout()),
this, SLOT(clearMessage()));
+   connect(_stats_timer_, SIGNAL(timeout()),
+   this, SLOT(showStats()));
+   d.statusbar_stats_timer_.start(1000);
 
// We don't want to keep the window in memory if it is closed.
setAttribute(Qt::WA_DeleteOnClose, true);
@@ -627,6 +631,13 @@ GuiView::GuiView(int id)
busySVG, SLOT(hide()));
connect(busySVG, SIGNAL(pressed()), this, 
SLOT(checkCancelBackground()));
 
+   stat_counts_ = new QLabel(statusBar());
+   stat_counts_->setAlignment(Qt::AlignCenter);
+   stat_counts_->setFrameStyle(QFrame::StyledPanel);
+   stat_counts_->hide();
+   statusBar()->addPermanentWidget(stat_counts_);
+
+
QFontMetrics const fm(statusBar()->fontMetrics());
 
zoom_slider_ = new QSlider(Qt::Horizontal, statusBar());
@@ -952,6 +963,7 @@ void GuiView::saveLayout() const
settings.setValue("icon_size", toqstr(d.iconSize(iconSize(;
settings.setValue("zoom_value_visible", zoom_value_->isVisible());
settings.setValue("zoom_slider_visible", zoom_slider_->isVisible());
+   settings.setValue("document_stats_enabled", stat_counts_enabled_);
 }
 
 
@@ -1001,6 +1013,9 @@ bool GuiView::restoreLayout()
zoom_in_->setVisible(show_zoom_slider);
zoom_out_->setVisible(show_zoom_slider);
 
+   stat_counts_ena

Re: Interesting discovery from automatic tools (python code)

2022-07-30 Thread Pavel Sanda
On Sat, Jul 30, 2022 at 12:31:57PM +0100, José Matos wrote:
> I think that this should be applied.

I wanted to commit for you, but this is what I get when trying to apply the 
patch:
patching file lib/lyx2lyx/lyx2lyx_tools.py
patching file lib/lyx2lyx/lyx_0_12.py
patching file lib/lyx2lyx/lyx_1_2.py
patching file lib/lyx2lyx/lyx_1_3.py
patching file lib/lyx2lyx/lyx_1_4.py
patching file lib/lyx2lyx/lyx_1_5.py
patching file lib/lyx2lyx/lyx_1_6.py
patching file lib/lyx2lyx/lyx_2_0.py
patching file lib/lyx2lyx/lyx_2_1.py
patching file lib/lyx2lyx/lyx_2_2.py
patching file lib/lyx2lyx/lyx_2_3.py
patching file lib/lyx2lyx/lyx_2_4.py
patching file lib/lyx2lyx/parser_tools.py
Hunk #3 succeeded at 479 with fuzz 1.
patch unexpectedly ends in middle of line
patch unexpectedly ends in middle of line

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


Re: [PATCH] Support \\*

2022-07-15 Thread Pavel Sanda
On Fri, Jul 15, 2022 at 08:17:35PM +0200, Jean-Marc Lasgouttes wrote:
> >>My specific use case for this is for short stanzas in a verse
> >>environment: \\* will prevent a page break in the middle of a stanza.
> >>
> >>For lack of a better term I've called this "Starred line break" though
> >>I'm sure it can be renamed to something more appropriate.
> >
> >Not sure either, but normal user won't get idea what is it for with
> >this naming. Could not find anything better than "Line break without page 
> >break".
> 
> Or maybe 'Line break (same page)'

Looks better.

> >Is the meaning of \\* stable enough across different environments?
> 
> I am not sure what you mean here, Pavel.

\\ is redefined in many LaTeX environments, I was wondering what is the
situation with \\*. I.e. Whether it is safe enough to rename '\\*' to 
'line break without pagebreak'.

> I am not very excited by the screen representation, as color coding is
> considered a bad thing, but I do not have a better idea right now.

We could paint new glyph, e.g. like the attached.
(Example of such plotting is also in the commit I refered in my earlier email.)

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


Re: [PATCH] Support \\*

2022-07-15 Thread Pavel Sanda
Dear Chris,

welcome here and sorry for the late reply.

On Mon, Jun 06, 2022 at 05:46:32PM -0700, Chris Spiegel wrote:
> I'm attaching two patches, one against git master, the other against
> the 2.3.x branch. These patches add a starred new line break
> formatting option (\\*) to complement "Ragged line break", i.e. the \\
> macro.

This is fileformat change, it can not go to 2.3, but only into master.
Also it would need to conversion routine in lyx2lyx for conversion
between different LyX versions (see e.g. commit 0ea9df7467a9b).
 
> My specific use case for this is for short stanzas in a verse
> environment: \\* will prevent a page break in the middle of a stanza.
> 
> For lack of a better term I've called this "Starred line break" though
> I'm sure it can be renamed to something more appropriate.  

Not sure either, but normal user won't get idea what is it for with
this naming. Could not find anything better than "Line break without page 
break".

Is the meaning of \\* stable enough across different environments?

> I've also given it the keyboard shortcut of meta-shift-enter, which is in the
> ballpark of the other newline-style formatting options.
> 
> I've been using this patch at least since the LyX 1.6.0 days, with no 
> problems.
> 
> Whether this is the best way to support \\* I'm not sure, but I do
> think having the ability to add \\* directly, rather than via ERT, is
> very useful.

I think it would be OK to add it. What do others think?

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


Re: [patch] Selection stats in statusbar

2022-07-14 Thread Pavel Sanda
On Thu, Jul 14, 2022 at 09:31:06AM +0200, Daniel wrote:
> >The drawback is that's it's difficult to understand the interaction between
> >the two timers now. I stared on the code for couple minutes and it was
> >not clear to me what is the idea behind your stop/start changes.
> 
> Some comments would probably have been good. I could try to add them if
> there is interest.

If I find little time I'll try the QTimer route and see whether we converge :)

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


Bug tracker accounts

2022-07-13 Thread Pavel Sanda
Dear LyXers,

we recently suffer massive spam abuse in our bug tracker. For the moment
we disabled automatized account creation and removed approx. 30k fake user
accounts.

While we tried to avoid removal of legit accounts (by pairing to existing
bug reports) some of this work was manual and could possibly lead to
inadvertent removal of real user (sorry!).

If new account needs to be (re)created, please send the request to mailling
list and we'll do it for you until new solution is found (captcha/migration
to different platform).

Sorry for the inconveniece,
Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [patch] Selection stats in statusbar

2022-07-13 Thread Pavel Sanda
On Wed, Jul 13, 2022 at 08:54:28AM +0200, Daniel wrote:
> Hi,
> 
> There is also a patch for instant counts at
> https://www.lyx.org/trac/ticket/12422. It works with delayed calculations. I
> have no idea how this does performance wise, but it might be worth checking
> out.

Yes, that's lazy man approach, using timer instead of parallel thread.
The advantage is that you avoid race-conditions (though I think you miss stop()
inside closeEvent()?).
The drawback is that's it's difficult to understand the interaction between
the two timers now. I stared on the code for couple minutes and it was
not clear to me what is the idea behind your stop/start changes.

JMarc's warning about ineeficiency of counting remain unaddressed, though
it migh not be visible because of 300ms update sampling frequency.

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


Re: [LyX/master] Check for icon aliases

2022-07-13 Thread Pavel Sanda
On Wed, Jul 13, 2022 at 01:11:56PM +0200, Jean-Marc Lasgouttes wrote:
> Le 13/07/2022 ?? 00:56, Pavel Sanda a écrit :
> >On Tue, Jul 12, 2022 at 10:52:18PM +0200, Jean-Marc Lasgouttes wrote:
> >>+QString getAlias(QString name) {
> >
> >Could we get the comment in the code, what is this function supposed to do?
> 
> Right, done now.

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


Re: [LyX/master] Check for icon aliases

2022-07-12 Thread Pavel Sanda
On Tue, Jul 12, 2022 at 10:52:18PM +0200, Jean-Marc Lasgouttes wrote:
> +QString getAlias(QString name) {

Could we get the comment in the code, what is this function supposed to do?

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


Re: [patch] Selection stats in statusbar

2022-07-12 Thread Pavel Sanda
On Tue, Jul 12, 2022 at 04:31:20PM -0400, Scott Kostyshak wrote:
> However, it seems to have a pretty big hit on performance. The way I
> checked was starting with select-all on a document, and then doing shift
> + up and seeing how long it took to get to the top. It took 16 seconds
> without the patch and 47 seconds with the patch. I don't have a good
> argument for a use case for this particular stress test, but it seems to
> raise a flag, and the document I used to test is not too long (it
> compiles to a 14 page PDF).

I see. Admittedly I used it only localy for couple paragraphs and it
did not occur to me to try selection of the whole document. 

In a local use even on my super-speedy repeat rate of keyboard
nothing is noticeable but when I select complete User Guide the
lag is indeed visible. One could perhaps disable the feature
if (to-from) is too big.

> I think it would be nice to add an option to show/remove it.

As you've guessed I am no fan of new options for details like this.

> If that doesn't work, would this be a good candidate for asynchronous
> calculation?

This would be indeed an option. We could show statistics for the whole
document or just selection when selected and update it in a parallel
thread once in a second or so. I have a feeling that MS Word is doing
something like this based on it's laggy updates of statusbar.

> I know I'm asking to do a lot of work

You are and I am nowhere close to having time for that :)

As such this change goes to my local patchset and I am rectracting
the proposal...

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


Re: Remove duplicate history entries in command buffer

2022-07-12 Thread Pavel Sanda
On Mon, Jul 11, 2022 at 02:25:49PM +0200, Kornel Benko wrote:
> Am Mon, 11 Jul 2022 13:37:31 +0200
> schrieb Pavel Sanda :
> 
> > On Mon, Jul 11, 2022 at 10:53:23AM +0200, Kornel Benko wrote:
> > > So the outcome may be a new preference?  
> > 
> > Please no.
> > 
> > Pavel
> 
> What is your preference?

I do not have strong opinion whether erasing from history or just not
duplicating last command is a better option.

JMarc's point about storing proper order in older commands makes sense in linux
shell history. In LyX I am not convinced, or rather I can't remember that I
really used sequences of commands except of those which are actually wrapped by
command-sequence lfun. 

But no hard opinion, except that this minute detail does not deserve new
lyx preference.

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


[patch] Selection stats in statusbar

2022-07-12 Thread Pavel Sanda
Hi,

I need to adhere precise word/character counts in sections of a document.
For this I need to have instantaneous visual feedback of stats when selecting
blocks of text.

The attached patch does this. Is there some objection to push this into master?
(If no objection raised I'll add string translation layer to the patch.)

Pavel
diff --git a/src/Text.cpp b/src/Text.cpp
index 7857e5e06c..6a7b80d93f 100644
--- a/src/Text.cpp
+++ b/src/Text.cpp
@@ -2146,6 +2146,18 @@ docstring Text::currentState(CursorData const & cur, 
bool devel_mode) const
}
}
 
+   // Stats if selection is done
+   if (cur.selection()) {
+   DocIterator from, to;
+   from = cur.selectionBegin();
+   to = cur.selectionEnd();
+   buf.updateStatistics(from, to);
+   int const words = buf.wordCount();
+   int const chars = buf.charCount(false);
+   int const chars_blanks = buf.charCount(true);
+   os << ", w:" << words << " c:" << chars << " cb:"<-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Remove duplicate history entries in command buffer

2022-07-11 Thread Pavel Sanda
On Mon, Jul 11, 2022 at 10:53:23AM +0200, Kornel Benko wrote:
> So the outcome may be a new preference?

Please no.

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


Re: Missing header using gcc-13

2022-06-28 Thread Pavel Sanda
On Mon, Jun 27, 2022 at 09:20:26PM +0100, José Matos wrote:
> On Mon, 27 Jun 2022 at 15:56, Pavel Sanda  wrote:
> 
> > Does including  fix the problem?
> > Pavel
> > --
> > lyx-devel mailing list
> > lyx-devel@lists.lyx.org
> > http://lists.lyx.org/mailman/listinfo/lyx-devel
> >
> 
> Yes, it is the only place where it is required. Other than that compiles
> and runs perfectly...

It's in. P
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


lyx.org emails

2022-06-28 Thread Pavel Sanda
Hi,

everyone owning @lyx.org address should have received few minuttes back an 
email 
with the subject "lyx.org email transition (hopefully) finished".

If you did not receive it let me know, so we can fix it.

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


Re: Missing header using gcc-13

2022-06-27 Thread Pavel Sanda
On Wed, Jun 22, 2022 at 11:00:18AM +0100, José Abílio Matos wrote:
> Hi,
>   just for fun, I have been compiling lyx with gcc-latest (gcc 13 in 
> development). This is the error I get:
> 
> /home/jamatos/lyx/lyx.anon/src/tex2lyx/Parser.cpp: In member function ???void 
> lyx::Parser::tokenize_one()???:
> /home/jamatos/lyx/lyx.anon/src/tex2lyx/Parser.cpp:857:60: error: 
> ???uint32_t??? does not name a type
> 857 | cerr << "ignoring a char: " << static_cast(c) 
> << "\n";
> |^~~~
> /home/jamatos/lyx/lyx.anon/src/tex2lyx/Parser.cpp:20:1: note: ???uint32_t??? 
> is defined in header ??; did you forget to ???#include 
> 
> 19 | #include 
> +++ |+#include 
> 20 | 
> 
> This is the only problem found, other than that everything works as expected. 
> :-)

Does including  fix the problem?
Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Output word wrapping

2022-06-07 Thread Pavel Sanda
On Wed, Jun 01, 2022 at 08:42:55AM +0200, Daniel wrote:
> On 2022-06-01 08:21, 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
> Actually, it seems that LyX-file output is not affected by setting the
> output line length. Is that a bug?

No, as tooltip says, this pref is for tex/etc export.

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


Re: trac time certificae expired?

2022-05-24 Thread Pavel Sanda
On Tue, May 24, 2022 at 09:13:31PM +1200, Andrew Parsloe wrote:
> My computer is definitely showing the correct date and time for my location.
> (24 May 2022, about 9:05 pm New Zealand time when I tried.)

Most likely our certificate for lyx.org expired.
Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [LyX/master] Add GUI for search-ignore

2022-05-10 Thread Pavel Sanda
On Tue, May 10, 2022 at 11:53:09AM +0200, Kornel Benko wrote:
> Am Sat, 30 Apr 2022 13:45:45 +0200 (CEST)
> schrieb Juergen Spitzmueller :
> 
> >  src/frontends/qt/ui/FindAndReplaceUi.ui |  157 
> > +--
> 
> We have a problem to test the new feature. Old test depended on a shortcut
> to enter formatted search. All format-features enabled.
> 
> Now, all features are disabled at start, but there is no shortcut to enable 
> them.
> As a consequence some of 'findadv'-tests are failing.
> Could we please add shortcuts to
>   'Select all'
> and maybe also to
>   'Deselect all'
> ?

Not sure I follow. You mean global key shortcut to enable some checkboxes
in advanced search GUI?

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


Re: LyX 2.4.0 (IM policy.xml ban on eps/pdf conversions)

2022-05-04 Thread Pavel Sanda
On Mon, Mar 07, 2022 at 06:13:10PM +0100, Pavel Sanda wrote:
> On Fri, Feb 04, 2022 at 10:36:57AM +, José Abílio Matos wrote:
> > On Wednesday, 2 February 2022 21.45.40 WET Pavel Sanda wrote:
> > > Jose, could I ask for pythonic help?
> > > We would need a routine in configure.py which check whether to remove 
> > > eps->png
> > > conversion in case IM bans those conversions. That could be done this way 
> > > by
> > > checking return status of the conversion. In bash that would be something
> > > like this:
> > > 
> > > echo '%!PS' > /tmp/.lyx_configure_test.eps
> > > convert  /tmp/.lyx_configure_test.eps /tmp/.lyx_configure_test.png
> > > if ! [ $? == 0 ] ; then
> > >   # remove eps->png conversion from configure settings, i.e. set 
> > > \converter
> > > "eps" "png" "" "" fi
> > > 
> > > 
> > > Completely different way would be mimicking what IM internally does with 
> > > GS
> > > when converting eps->png. I already checked little bit and unfortunately 
> > > it
> > > won't be oneliner if we want to get resolution right. But probably doable
> > > with additional script of our own. Pavel
> > 
> > I will look into this in the weekend.
> > 
> > 
> > At some point I will want to overhaul the configure.py script.
> > The purpose is, among others, to simplify the code required to do this kind 
> > of tests.
> > 
> > The test above is relatively easy to do.
> > Something that I should, probably, take into account is the order of the 
> > tests.
> > 
> > In the sense that if we different \convert lines we probably retain the 
> > last...
> > 
> 
> ping :)

ping :)

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


Re: Back

2022-05-04 Thread Pavel Sanda
On Tue, May 03, 2022 at 11:19:16AM -0400, Richard Kimberly Heck wrote:
> Sorry for disappearing there for a while. I had some difficult personal
> circumstances and an incredibly busy semester and just had to withdraw from
> everything else until things settled down. Which they now have.

I'm happy you recovered and see you on the list again!
 
> Where are things with respect to LyX 2.4.0? I'm happy to resume my role as
> release manager for that project, if that's still required.

I believe so.

As others noted it might be best to just quickly release alpha 4 without
much damage control, and sort out the issues raised before/meanwhile for beta 1.

Per your own request I prepared list of bugs for the transitions
https://wiki.lyx.org/Devel/LyX24Road
and I recommend that others add to the list their own issues.

For the ghostcript issue I think I found the solution already but requested
some python help from Jose and will ping him again now :)

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


Re: Quick newbie question

2022-05-02 Thread Pavel Sanda
On Mon, May 02, 2022 at 01:04:23PM +0200, Lorenzo Bertini wrote:
> >Update: file was never gone, just in its folder "3rdparty". Compilation
> >now works after countless attemps, and I didn't really change anything :).
> 
> Problem is here again after another attempted bisect, failure, and restoring
> to master, same as last time:
> 
> >In file included from ./../support/ForkedCalls.h:17,
> > from ForkedCalls.cpp:15:
> >./../support/signals.h:15:10: fatal error: nod.hpp:
> 
> File "nod.hpp" exists in "3rdparty/nod".

Did you try calling autogen.sh before the build?

> On a side note, I can't build anything from the old builds. Configure in
> 2.3.6.2 reported that it couldn't build a qt executable, so i had to add
> "--enable-qt5", but then it said there was an undefined reference to "boost
> basic_regex" (but I have boost libraries installed and working). At that

If boost is a problem then you can try to use "--with-included-boost" when
you run configure.


> point I went back to master, cleaned and configured again, and now for some
> reason it needs "--enable-qt5" whereas before it didn't on master.

That means you are either not on master HEAD or you did not clean properly.
For cleaning you can always check via "git status".

> 
> Not being able to build older versions really hurts because i can't bisect.
> Can someone help me out? I'm on debian 11 stable. I can build master just
> fine.

Building back in history will work only to the point where qt5 is already
present in the master. If the bug is older it will be difficult.

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


Re: Expand debug to contain more than 31 cases

2022-04-26 Thread Pavel Sanda
On Tue, Apr 26, 2022 at 03:35:30PM +0200, Jean-Marc Lasgouttes wrote:
> Le 26/04/2022 ?? 14:58, Pavel Sanda a écrit :
> >On Tue, Apr 26, 2022 at 02:28:08PM +0200, Pavel Sanda wrote:
> >>>I read somewhere that 64 bit for long long was a 'should' and not a 'must'.
> >
> >There is subtlety here, which might be the source of confusion. The standard 
> >does not tell you
> >long long needs to be *implemented* by 64bits. It just tells you to contain 
> >the range of 2^64.
> >So standard does not prohibit you to write compiler which uses 65 bits for 
> >long long.
> 
> And if I understand correctly, C++11 tells you that 'long long' has to
> exist, which was not the case before if I am not mistaken.

Yes, 1998 version of C++ Standard does not know long long, while C++11
knows it and introduces  with LLONG_MAX, but leaving the definition
on Standard C library header .

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


Re: Expand debug to contain more than 31 cases

2022-04-26 Thread Pavel Sanda
On Tue, Apr 26, 2022 at 02:28:08PM +0200, Pavel Sanda wrote:
> > I read somewhere that 64 bit for long long was a 'should' and not a 'must'.

There is subtlety here, which might be the source of confusion. The standard 
does not tell you 
long long needs to be *implemented* by 64bits. It just tells you to contain the 
range of 2^64.
So standard does not prohibit you to write compiler which uses 65 bits for long 
long.

So if you were to write API with standardized data structures you need to send 
through some channel,
you better be sure about size of int implementations.

But there is no need to worry that 2^33 won't be contained in long long as is 
our usecase.

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


Re: Expand debug to contain more than 31 cases

2022-04-26 Thread Pavel Sanda
On Mon, Apr 25, 2022 at 09:35:46PM +0200, Kornel Benko wrote:
> > Can you explain to me what is the reason for "weakly opposing" it?
> 
> Yes, the code does no harm, only gave me a guaranty.
> I read somewhere that 64 bit for long long was a 'should' and not a 'must'.

Nope, we are in the 'must' regime. Or rather 'shall' which is used in the 
standard.

In ANSI ISO/IEC 9899 (second edition 1999-12-01) "Programming languages - C"
(the one I easily have access to right now and which is referenced by C++ norm):

4.
In this International Standard, "shall" is to be interpreted as a requirement 
on an implementation or on a program; ...


5.2.4.2.1 Size of integer types
.. 
Their implementation-defined values shall be equal or greater in magnitude 
(absolute value) to those shown, with the same sign.
...
- minimum value for an object of type long long int LLONG_MIN 
-9223372036854775807 // ?(2^63 - 1)
- maximum value for an object of type long long int LLONG_MAX 
+9223372036854775807 // 2^63 - 1 
- maximum value for an object of type unsigned long long int ULLONG_MAX 
18446744073709551615 // 2^64 - 1

> But int64_t _has_ to contain valid 64 bits.

I hope I made clear long long satisfies your thirst for 33 bits as well and 
does not rely on any unnecessary includes.

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


Re: Expand debug to contain more than 31 cases

2022-04-25 Thread Pavel Sanda
On Mon, Apr 25, 2022 at 10:10:26AM +0200, Kornel Benko wrote:
> Am Sun, 24 Apr 2022 21:45:13 +0200
> schrieb Pavel Sanda :
> 
> > On Fri, Apr 22, 2022 at 01:56:20PM +0200, Kornel Benko wrote:
> > > Try to use
> > >   $ lyx -dbg
> > > it should display
> > >   ...
> > >   4294967296   debug ...
> > > then 1L would be correct.  
> > 
> > Seems to be correct now.
> > 
> > > > > +// Make sure at compile time that sizeof(unsigned long long) >= 8
> > > > > +typedef char p__LINE__[ (sizeof(unsigned long long) > 7) ? 1 : -1];  
> > > > >   
> > > > 
> > > > long long is supposed to be able to represent values between -(2^63 -1) 
> > > > to 2^63 -1
> > > > so I do not think this check is necessary.  
> > > 
> > > I wanted to be sure ...  
> > 
> > I do not see any ambiguity here. Mention of long long int goes back at 
> > least to 
> > ANSI C norm from 1998 and the range of 2^64 is already there.
> > 
> > Pavel
> 
> Pavel, I'd like to see the output of the following c++ source
>   #include 
> 
> compiled with
>   $ c++ -E -g3

The machine where it broke shows this:
https://pastebin.com/ubZVNKdr

> because I prefer to use something like uint64_t over 'unsigned long long'.

I dislike it because we use long long on bunch of different places in our
code already. This is introducing not yet used type depending on special header.
This might break on whatever strange arch ppl try to compile for no obvious 
gain.

> Other than this, if the test is really too itching, I am not opposing too 
> strong to
> remove it.

I just pointed out that long long needs to contain 64 bit range as defined by 
C(++) standard.
Can you explain to me what is the reason for "weakly opposing" it?

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


Re: Expand debug to contain more than 31 cases

2022-04-24 Thread Pavel Sanda
On Fri, Apr 22, 2022 at 01:56:20PM +0200, Kornel Benko wrote:
> Try to use
>   $ lyx -dbg
> it should display
>   ...
>   4294967296   debug ...
> then 1L would be correct.

Seems to be correct now.

> > > +// Make sure at compile time that sizeof(unsigned long long) >= 8
> > > +typedef char p__LINE__[ (sizeof(unsigned long long) > 7) ? 1 : -1];  
> > 
> > long long is supposed to be able to represent values between -(2^63 -1) to 
> > 2^63 -1
> > so I do not think this check is necessary.
> 
> I wanted to be sure ...

I do not see any ambiguity here. Mention of long long int goes back at least to 
ANSI C norm from 1998 and the range of 2^64 is already there.

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


Re: Expand debug to contain more than 31 cases

2022-04-22 Thread Pavel Sanda
On Fri, Apr 22, 2022 at 12:28:06PM +0200, Kornel Benko wrote:
> Am Thu, 21 Apr 2022 15:38:23 +0200
> schrieb Pavel Sanda :
> 
> > On Thu, Apr 21, 2022 at 02:53:37PM +0200, Jean-Marc Lasgouttes wrote:
> > > Do you have a better idea?  
> > 
> > long long ?
> > Pavel
> 
> Ok, is the attached working for you?

It compiles, I did not try to run (i.e. check whether literal 1L is correct).

> +// Make sure at compile time that sizeof(unsigned long long) >= 8
> +typedef char p__LINE__[ (sizeof(unsigned long long) > 7) ? 1 : -1];

long long is supposed to be able to represent values between -(2^63 -1) to 2^63 
-1
so I do not think this check is necessary.

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


Re: Expand debug to contain more than 31 cases

2022-04-21 Thread Pavel Sanda
On Thu, Apr 21, 2022 at 02:53:37PM +0200, Jean-Marc Lasgouttes wrote:
> Do you have a better idea?

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


Re: Expand debug to contain more than 31 cases

2022-04-21 Thread Pavel Sanda
On Tue, Apr 19, 2022 at 11:12:06AM +0200, Kornel Benko wrote:
> > I am not sure that we need a verbose level yet. What about
> > -dbg find => FINDSHORT
> > -dbg find --verbose => FIND
> > 
> > JMarc
> 
> I propose to do it as a next step. Better not too many changes at once IMO.

make[5]: Entering directory '/lyx/src/support'
  CXX  debug.o
In file included from debug.cpp:15:0:
./../support/debug.h:40:10: error: 'uint64_t' does not name a type
  typedef uint64_t base_type;


Well, not that small change. On some gcc versions you need to include cstdint
header to have uint64_t available (AFAIK we don't use uint64_t anywhere else
in the code).
And including  in debug.h which is used everywhere is not great idea.

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


Re: Opening activated branch insets

2022-04-16 Thread Pavel Sanda
On Sat, Apr 16, 2022 at 04:12:38PM +0200, Jean-Marc Lasgouttes wrote:
> >>It turned out to be even easier, because no one removed the old code
> >>when this feature was killed, it's just called assign.
> >>
> >>Patch attached. I'll strip context menu entry before commiting unless
> >>someone does not actively ask for it.
> >
> >Looks good, except that "assign" does not seem to cater for inverted
> >branches.

Easy one.

> Also, one should decide whether master or child status matters.

Right, I prefer child, as once this lfun is bound, it will be triggered on the
edited inset - i.e. typically child.

It's in 02ffd6dd70be.

Thanks both for the feedback,
Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Opening activated branch insets

2022-04-15 Thread Pavel Sanda
On Fri, Apr 15, 2022 at 02:41:53AM +0200, Pavel Sanda wrote:
> On Fri, Apr 15, 2022 at 12:01:04AM +0200, Jean-Marc Lasgouttes wrote:
> > Le 13/04/2022 ?? 14:39, Pavel Sanda a écrit :
> > >So changing the core of the patch to something like
> > >
> > >+ case LFUN_BRANCH_SYNC_ALL:
> > >+ lyx::dispatch(FuncRequest(LFUN_INSET_FORALL, "Branch:" + 
> > >params_.branch + " inset-toggle auto"));
> > >+ break;
> > >
> > >would be acceptable for you?
> > 
> > Sure, once the "auto" thing is implemented :)
> 
> I thought that's only question of launching github copilot nowadays :)
> (Planned to look at that after your ack.)

It turned out to be even easier, because no one removed the old code
when this feature was killed, it's just called assign.

Patch attached. I'll strip context menu entry before commiting unless
someone does not activaly ask for it.

Pavel
diff --git a/lib/ui/stdcontext.inc b/lib/ui/stdcontext.inc
index ed9a9da9fa..1448ee533b 100644
--- a/lib/ui/stdcontext.inc
+++ b/lib/ui/stdcontext.inc
@@ -535,6 +535,7 @@ Menuset
OptItem "Deactivate Branch in Master|v" 
"branch-master-deactivate"
OptItem "Invert Inset|I" "branch-invert"
OptItem "Add Unknown Branch|w" "branch-add"
+   OptItem "Sync all|y" "branch-sync-all"
End
 
 #
diff --git a/src/FuncCode.h b/src/FuncCode.h
index 20231eb164..8337c1f921 100644
--- a/src/FuncCode.h
+++ b/src/FuncCode.h
@@ -502,6 +502,7 @@ enum FuncCode
LFUN_SPELLING_REMOVE_LOCAL, // jspitzm 20210307
LFUN_FINISHED_DOWN, // lasgouttes 20210629
LFUN_FINISHED_UP,   // lasgouttes 20210629
+   LFUN_BRANCH_SYNC_ALL,   // sanda 20220415
LFUN_LASTACTION // end of the table
 };
 
diff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index ea60f53754..c88c1b9873 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -452,6 +452,15 @@ void LyXAction::init()
  */
{ LFUN_BRANCH_INSERT, "branch-insert", Noop, Edit },
 
+/*!
+ * \var lyx::FuncCode lyx::LFUN_BRANCH_SYNC_ALL
+ * \li Action: Open/close all insets of selected branch (depending on its 
selection status).
+ * \li Syntax: branch-toggle-all
+ * \li Origin: sanda, 15 April 2022
+ * \endvar
+ */
+   { LFUN_BRANCH_SYNC_ALL, "branch-sync-all", AtPoint, Buffer },
+
 /*!
  * \var lyx::FuncCode lyx::LFUN_BRANCH_INVERT
  * \li Action: Toggles inversion status of branch inset.
diff --git a/src/insets/InsetBranch.cpp b/src/insets/InsetBranch.cpp
index 7a102ceab6..1ff7f248b4 100644
--- a/src/insets/InsetBranch.cpp
+++ b/src/insets/InsetBranch.cpp
@@ -224,6 +224,9 @@ void InsetBranch::doDispatch(Cursor & cur, FuncRequest & 
cmd)
case LFUN_BRANCH_ADD:
lyx::dispatch(FuncRequest(LFUN_BRANCH_ADD, params_.branch));
break;
+   case LFUN_BRANCH_SYNC_ALL:
+   lyx::dispatch(FuncRequest(LFUN_INSET_FORALL, "Branch:" + 
params_.branch + " inset-toggle assign"));
+   break;
case LFUN_INSET_TOGGLE:
if (cmd.argument() == "assign")
setStatus(cur, isBranchSelected() ? Open : Collapsed);
@@ -276,6 +279,10 @@ bool InsetBranch::getStatus(Cursor & cur, FuncRequest 
const & cmd,
flag.setEnabled(buffer().parent() && isBranchSelected());
break;
 
+   case LFUN_BRANCH_SYNC_ALL:
+   flag.setEnabled(known_branch);
+   break;
+
case LFUN_INSET_TOGGLE:
if (cmd.argument() == "assign")
flag.setEnabled(true);
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Opening activated branch insets

2022-04-14 Thread Pavel Sanda
On Fri, Apr 15, 2022 at 12:01:04AM +0200, Jean-Marc Lasgouttes wrote:
> Le 13/04/2022 ?? 14:39, Pavel Sanda a écrit :
> >So changing the core of the patch to something like
> >
> >+ case LFUN_BRANCH_SYNC_ALL:
> >+ lyx::dispatch(FuncRequest(LFUN_INSET_FORALL, "Branch:" + 
> >params_.branch + " inset-toggle auto"));
> >+ break;
> >
> >would be acceptable for you?
> 
> Sure, once the "auto" thing is implemented :)

I thought that's only question of launching github copilot nowadays :)
(Planned to look at that after your ack.)

> I still have reservations about defining lfuns that are just command
> sequences, but I think we need to replace the "call" lfun (that nobody uses
> I suspect) with a real way to define lfuns in text files.

Right, lua-lyx for 2.5 release :)

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


Re: your mail

2022-04-14 Thread Pavel Sanda
On Thu, Apr 14, 2022 at 01:58:57PM -0700, Nathan Blodgett wrote:
> would you like to maintain this at pacstall-programs, or use your own repo if 
> you want.

Generally we don't do distros package maintenance and I would be very surprised 
if
someone from this list jumped for maintenance on even smaller niche 
distribution stream.
(Happy to be proved wrong though).

Apart from that I question the wisdom of including LyX into AUR-like repo. Our
package is already in the main repo, our major release cycles are slower than
debian's and if need be debian backports and ubuntu ppa already cover the need
of updates to possibly new major version. Doing all the maintenance work for
just minor version updates seem to be waste of time (which - frankly - would be
better saved by uploading minors into backports/ppa). But YMMV :)

> include a section on how to install at wiki and/or downloads section would be 
> great.

Anyone can contribute to wiki.lyx.org, so please be our guest to introduce the 
way fits you best...

Good luck and cheers!
Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Opening activated branch insets

2022-04-13 Thread Pavel Sanda
On Wed, Apr 13, 2022 at 12:04:00PM +0200, Jean-Marc Lasgouttes wrote:
> Le 13/04/2022 ?? 11:48, Pavel Sanda a écrit :
> >On Mon, Apr 11, 2022 at 02:17:44PM +0200, Jean-Marc Lasgouttes wrote:
> >>Le 11/04/2022 ?? 13:44, Pavel Sanda a écrit :
> >>>So what is your reading of the results?
> >>>Seems to me no interest. As a result I would favor committing my patch
> >>>minus context menu UI plus any changes you might have for the wording.
> >>>And I'll add some note into manuals.
> >>
> >>I did read your patch, but I do not know what the use case is.
> >
> >My use case is opening/closing all branch insets of a given name.
> 
> No, you toggle them?*. What happens depends on their current state.

Oops, looking at my patch again I understand why both of you have problems with 
my approach :)
I have bilingual documents where all insets of one language are all open or 
closed,
hence the toggling worked. But of course you are right, it should be just open 
or close,
toggling only worked by chance. Sorry for the confusion.

> >We would need to pass the "correct" branch name into lfun call.
> >You want inset-forall to sniff around for proper name? Does not look right.
> >Or is there way how to pass that string via specific parameter in context 
> >menu definition?
> 
> The branch inset knows whether it should be open or closed wrt its
> activeness status. I think we can use this with a "inset-toggle auto" or
> something.

So changing the core of the patch to something like 

+ case LFUN_BRANCH_SYNC_ALL:
+ lyx::dispatch(FuncRequest(LFUN_INSET_FORALL, "Branch:" + 
params_.branch + " inset-toggle auto"));
+ break;

would be acceptable for you?

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


Re: Opening activated branch insets

2022-04-13 Thread Pavel Sanda
On Mon, Apr 11, 2022 at 02:17:44PM +0200, Jean-Marc Lasgouttes wrote:
> Le 11/04/2022 ?? 13:44, Pavel Sanda a écrit :
> >So what is your reading of the results?
> >Seems to me no interest. As a result I would favor committing my patch
> >minus context menu UI plus any changes you might have for the wording.
> >And I'll add some note into manuals.
> 
> I did read your patch, but I do not know what the use case is.

My use case is opening/closing all branch insets of a given name.

> For a given branch, is closes open branches and opens closed ones? Setting
> them to some preferred state (active=open) would seem more useful to me.

I bound the lfun to branch inset context menu so toggling made sense.
But I can make the lfun more generic, i.e. allowing open/close/toggle arguments.

> >The other exchange with JMarc seem to go different direction if I understand
> >it right...
> 
> I am not totally sure, since I think we can extend a bit the semantics of
> inset-toggle to make your patch actually useful.

We would need to pass the "correct" branch name into lfun call.
You want inset-forall to sniff around for proper name? Does not look right.
Or is there way how to pass that string via specific parameter in context menu 
definition?

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


Re: Opening activated branch insets

2022-04-11 Thread Pavel Sanda
On Sat, Apr 02, 2022 at 10:38:13AM -0400, Scott Kostyshak wrote:
> On Fri, Apr 01, 2022 at 11:15:53PM +0200, Pavel Sanda wrote:
> > On Thu, Mar 31, 2022 at 10:53:38AM -0400, Scott Kostyshak wrote:
> > > If you agree with this proposal, I can ask on lyx-users. If
> > > you disagree, let's continue discussion and hopefully someone else has
> > > an opinion.
> > 
> > I am completely fine with your proposal, please ask on user list.
> > If no one is interested we can just leave it with existing LFUN
> > and note in documentation...
> 
> Sounds good. I sent the email.

So what is your reading of the results?
Seems to me no interest. As a result I would favor committing my patch
minus context menu UI plus any changes you might have for the wording.
And I'll add some note into manuals.

> JMarc came up with a solution that I think might actually be closer to
> what you want, in the sense that you could open all insets of all
> activated branch insets, and close all insets of all deactivated branch
> insets.

The other exchange with JMarc seem to go different direction if I understand
it right...

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


Re: "flatten" branch insets

2022-04-04 Thread Pavel Sanda
On Sun, Apr 03, 2022 at 09:29:16PM +0200, Jean-Marc Lasgouttes wrote:
> >I am not sure. Certainly not in the exact form above.
> >1) I need only to affect branches with certain name, not all.
> 
> If it is _a_ certain name, one can put it instead of the *.
> We could allow for globbing (easier to understand then regex IMO) if we have
> support for that in Qt or std::regex.
> 
> >2) I want to be able to toggle them when they are inactive.
> 
> You would need two commands, maybe in sequence. Or we could add the argument
> "auto" to inset-toggle that would close insets that do not produce output
> and open those which produce output (which is the intent as  I understand
> it).

Well both my points are done in the patch I sent earlier.
The branch name is taken from the inset you clicked on and toggling is done
no matter whether the branch is active or inactive...

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


Re: "flatten" branch insets

2022-04-03 Thread Pavel Sanda
On Sat, Apr 02, 2022 at 10:31:15AM -0400, Scott Kostyshak wrote:
> I think that your proposal would actually work for Pavel's intended
> workflow as well. Pavel, do I understand correctly that
> 
>   inset-forall Branch:*:active inset-toggle toggle
> 
> would do what you want?

I am not sure. Certainly not in the exact form above.
1) I need only to affect branches with certain name, not all.
2) I want to be able to toggle them when they are inactive.

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


Re: Opening activated branch insets

2022-04-01 Thread Pavel Sanda
On Thu, Mar 31, 2022 at 10:53:38AM -0400, Scott Kostyshak wrote:
> If you agree with this proposal, I can ask on lyx-users. If
> you disagree, let's continue discussion and hopefully someone else has
> an opinion.

I am completely fine with your proposal, please ask on user list.
If no one is interested we can just leave it with existing LFUN
and note in documentation...

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


Re: bg.po update

2022-04-01 Thread Pavel Sanda
On Fri, Apr 01, 2022 at 09:28:26AM +0200, Jürgen Spitzmüller wrote:
> Am Donnerstag, dem 31.03.2022 um 19:35 +0300 schrieb Veselin:
> > Attached is an updated file from lyx 2.4.0dev for the bulgarian
> > translation.
> > 
> > I send you an update as the translation was under 50%.
> 
> Thanks. Committed.

Yes, thanks.

Veselin, could you please do one more check for us?
In the file layouttranslations, current version is here (or in git master if 
you work with it):
https://www.lyx.org/trac/browser/lyxgit/lib/layouttranslations?rev=46c6c40bea6ac75474b712b718b5903a8451bd31
there is "bg" section  with translations used for specific words generated in 
latex output.

Could you specifically look for these:

"List of Listings"
"Nomenclature[[output]]" (The string that is output to PDF for the nomenclature 
list)
"see equation[[nomencl]]"
"page[[nomencl]]"
"Notes[[Endnotes]]" (The header string of endnotes (with "Endnotes (Basic)" and 
"Footnotes as Endnotes (Basic)" modules). This is to be distinguished from 
"Notes" used by the Notes inset (which is more an annotation than a list of 
(end)notes))

and explicitely confirm they are correct (or fix them in bg.po in case of 
problem)?

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


Re: Bug#1008257: lyx: bash-completion not working

2022-04-01 Thread Pavel Sanda
On Wed, Mar 30, 2022 at 09:50:48AM -0300, Hernán Gustavo Solari wrote:
> I hereby grant permission to use my work for LyX under the license
> GPL version 2 or later.
> 
> I am attaching the last version of the bash-completion script with a
> minor bug-fix (*)

I commited your changes and added you to our hall of fame for 2.4.

I think you are at the moment the one who understand most about
completion scripts in our team so please do not hesitate to
improve it with further patches :)

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


Re: Bug#1008257: lyx: bash-completion not working

2022-03-30 Thread Pavel Sanda
On Sun, Mar 27, 2022 at 01:05:20PM -0300, Hernán Gustavo Solari wrote:
> I have extended the completion for lyx. This is not a bug fix, though.

Thanks, I'll commit your changes.
Since this is already proper contribution to our codebase, could you please
send us mail to the development list (e.g. by replying to this email) stating:

"I hereby grant permission to use my work for LyX under the license GPL
version 2 or later."

We will add you to our credits then.

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


Re: Opening activated branch insets

2022-03-29 Thread Pavel Sanda
On Tue, Mar 29, 2022 at 02:30:26PM -0400, Scott Kostyshak wrote:
> > > and/or in the context menu when right-clicking on a branch?
> > 
> > The attached patch solves the problem for me.
> > I would like to get at least the lfun to the master (I can add note about 
> > this 
> > lfun for binding to tutorial). Objections?
> 
> I find "selected branch" confusing in the documentation. It makes it
> seem we should select the branch and then run the LFUN. Should we say
> explicitly "the branch in front of the cursor" ? I didn't look at
> similar functions so perhaps "selected x" is indeed consistent with
> others. If so, please ignore.

I do not have any strong opinion about the wording.
Could you update the patch so the wording is understandable? I am not good
at UI-friendly designs :)


> > If you like I can add the entry to the context menu of branch inset (part 
> > of the
> > current patch), but I am equivalently happy to have in just in my private
> > patchset.
> 
> Perhaps ask on lyx-users? I find it strange to *toggle*. Why do you want
> to toggle rather than just "open all" or "close all" ? Can you describe
> a specific use case to toggle rather than open all or close all? Perhaps
> you are trying to be considerate of not taking up too many options?

Exactly, I wanted to avoid unnecesary menu items. If it was single inset
one of the open/close items could be hidden, but not with many items...
And again no strong opinions here; since no one objected during last 6 years
it's probably only my issue and I am happy not to touch UI in master
if lfun is made available for keybinding.

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


Re: Opening activated branch insets

2022-03-29 Thread Pavel Sanda
On Tue, Mar 29, 2022 at 07:54:31AM -0400, Scott Kostyshak wrote:
> On Tue, Mar 29, 2022 at 01:33:32PM +0200, Pavel Sanda wrote:
> > On Mon, Mar 28, 2022 at 07:52:33PM -0400, Scott Kostyshak wrote:
> > > > Is this intended? How do I open all activated branch insets now?
> > > 
> > > I don't know if we have that functionality. Not sure it helps, but to
> > > open all branch insets of "my-branch-name":
> > > 
> > >   inset-forall Branch:my-branch-name inset-toggle open
> > > 
> > > And to close:
> > > 
> > >   inset-forall Branch:my-branch-name inset-toggle close
> > > 
> > > Assuming the above doesn't satisfy your workflow, then we should make a
> > > new LFUN that handles branch insets according to whether they are
> > > activated.
> > 
> > To have an option to open/close them all would be helpful.
> > I don't push for the automatic toggling we used to have but some
> > way how to chage that through UI would be helpful.
> > What would be UI way which wouldn't disturb you?
> 
> I guess in Document > Settings > Branches? 

First I thought it's good idea, but if I added button for toggling
with your lfun, it would be triggered immediately instead after
confirming dialog. Or one would need new params just for this which
feels we are stretching things too far..

> and/or in the context menu when right-clicking on a branch?

The attached patch solves the problem for me.
I would like to get at least the lfun to the master (I can add note about this 
lfun for binding to tutorial). Objections?

If you like I can add the entry to the context menu of branch inset (part of the
current patch), but I am equivalently happy to have in just in my private
patchset.

Pavel
diff --git a/lib/ui/stdcontext.inc b/lib/ui/stdcontext.inc
index ed9a9da9fa..73e9685d68 100644
--- a/lib/ui/stdcontext.inc
+++ b/lib/ui/stdcontext.inc
@@ -535,6 +535,7 @@ Menuset
OptItem "Deactivate Branch in Master|v" 
"branch-master-deactivate"
OptItem "Invert Inset|I" "branch-invert"
OptItem "Add Unknown Branch|w" "branch-add"
+   OptItem "Toggle All" "branch-toggle-all"
End
 
 #
diff --git a/src/FuncCode.h b/src/FuncCode.h
index 20231eb164..4306e30eb9 100644
--- a/src/FuncCode.h
+++ b/src/FuncCode.h
@@ -502,6 +502,7 @@ enum FuncCode
LFUN_SPELLING_REMOVE_LOCAL, // jspitzm 20210307
LFUN_FINISHED_DOWN, // lasgouttes 20210629
LFUN_FINISHED_UP,   // lasgouttes 20210629
+   LFUN_BRANCH_TOGGLE_ALL, // sanda 20220322
LFUN_LASTACTION // end of the table
 };
 
diff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index ea60f53754..a7dcf29deb 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -452,6 +452,15 @@ void LyXAction::init()
  */
{ LFUN_BRANCH_INSERT, "branch-insert", Noop, Edit },
 
+/*!
+ * \var lyx::FuncCode lyx::LFUN_BRANCH_TOGGLE_ALL
+ * \li Action: Toggles open/close status of all insets of selected branch.
+ * \li Syntax: branch-toggle-all
+ * \li Origin: sanda, 29 March 2022
+ * \endvar
+ */
+   { LFUN_BRANCH_TOGGLE_ALL, "branch-toggle-all", AtPoint, Buffer 
},
+
 /*!
  * \var lyx::FuncCode lyx::LFUN_BRANCH_INVERT
  * \li Action: Toggles inversion status of branch inset.
diff --git a/src/insets/InsetBranch.cpp b/src/insets/InsetBranch.cpp
index 2b60ca6f44..c486514963 100644
--- a/src/insets/InsetBranch.cpp
+++ b/src/insets/InsetBranch.cpp
@@ -224,6 +224,9 @@ void InsetBranch::doDispatch(Cursor & cur, FuncRequest & 
cmd)
case LFUN_BRANCH_ADD:
lyx::dispatch(FuncRequest(LFUN_BRANCH_ADD, params_.branch));
break;
+   case LFUN_BRANCH_TOGGLE_ALL:
+   lyx::dispatch(FuncRequest(LFUN_INSET_FORALL, "Branch:" + 
params_.branch + " inset-toggle toggle"));
+   break;
case LFUN_INSET_TOGGLE:
if (cmd.argument() == "assign")
setStatus(cur, isBranchSelected() ? Open : Collapsed);
@@ -276,6 +279,10 @@ bool InsetBranch::getStatus(Cursor & cur, FuncRequest 
const & cmd,
flag.setEnabled(buffer().parent() && isBranchSelected());
break;
 
+   case LFUN_BRANCH_TOGGLE_ALL:
+   flag.setEnabled(known_branch);
+   break;
+
case LFUN_INSET_TOGGLE:
if (cmd.argument() == "assign")
flag.setEnabled(true);
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Opening activated branch insets

2022-03-29 Thread Pavel Sanda
On Mon, Mar 28, 2022 at 07:52:33PM -0400, Scott Kostyshak wrote:
> > Is this intended? How do I open all activated branch insets now?
> 
> I don't know if we have that functionality. Not sure it helps, but to
> open all branch insets of "my-branch-name":
> 
>   inset-forall Branch:my-branch-name inset-toggle open
> 
> And to close:
> 
>   inset-forall Branch:my-branch-name inset-toggle close
> 
> Assuming the above doesn't satisfy your workflow, then we should make a
> new LFUN that handles branch insets according to whether they are
> activated.

To have an option to open/close them all would be helpful.
I don't push for the automatic toggling we used to have but some
way how to chage that through UI would be helpful.
What would be UI way which wouldn't disturb you?

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


Opening activated branch insets

2022-03-28 Thread Pavel Sanda
Hi,
in my memory when some branch was activated in document settings all its insets 
got opened, which was handy.
But it does not seem to function that way anymore.

Is this intended? How do I open all activated branch insets now?
Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Bug#1008257: lyx: bash-completion not working

2022-03-27 Thread Pavel Sanda
On Sat, Mar 26, 2022 at 09:36:47AM -0300, Hernán Gustavo Solari wrote:
> Great!
> 
>  Somebody knowlegeable in bash-completion and the lyx command line
> should look to the lyx-completion-script

All patches are welcome :)
Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


completion script update

2022-03-25 Thread Pavel Sanda
Hi,

per a debian bug report the bash-completion script we provide does not 
seem to work anymore due to outdated syntax.

Attaching patch to fix the situation (works on debian stable).

Anyone around actively using bash-completion to test as well?

Pavel
diff --git a/lib/scripts/bash_completion b/lib/scripts/bash_completion
index 868884cf13..4d7b914e2a 100644
--- a/lib/scripts/bash_completion
+++ b/lib/scripts/bash_completion
@@ -1,7 +1,7 @@
 # lyx(1) completion 
 # Copyleft 2010 Cengiz Gunay 
 
-have lyx &&
+_have lyx &&
 _lyx()
 {
 local cur g last
@@ -65,5 +65,4 @@ _lyx()
# turn it off if necessary
test $g -eq 0 && shopt -u extglob
 
-}
-[ "${have:-}" ] && complete -F _lyx $filenames lyx
+} && complete -F _lyx $filenames lyx
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: LyX in the Snap Store

2022-03-23 Thread Pavel Sanda
On Wed, Mar 23, 2022 at 12:05:15PM +, Igor Ljubuncic wrote:
> What I was thinking is a joint effort. If you do want to maintain snaps
> long-term (emphasis on if), then you would need to understand and master
> the process, which is why it is handy for you to get familiar with the
> tooling.

Unfortunately I do not have time for mastering snap tooling in any foreseeable
future, I am sorry.

> The big advantage in terms of maintenance is that you then do not need to
> rebuild and recompile everything for every distro.

We do not really maintain LyX in linux distros, it's mostly their effort...

I consider snap to be nice thing to have more from archeology perspective,
when you need to run decade old code, but for the current codebase the
current situation of distros managing LyX on their own is better for us.

It would be quite burdersome to track all various CVEs for imagemagick or
ghostscript and continuously provide security updates for the whole
toolchain... We are too interdependent on the environment that unless someone
like you volunteers to take this burden on his shoulders it seems the needed
manpower is beyond what we have at our disposal...

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


Re: LyX in the Snap Store

2022-03-22 Thread Pavel Sanda
On Tue, Mar 22, 2022 at 11:45:14AM +, Igor Ljubuncic wrote:
> I wanted to ask you if you'd be interested in packaging LyX as a snap and
> publishing it in the Snap Store?

We would be definitiely interested in having it.

> I know this would be a significant effort, but we could help of course, and
> also feature LyX once it's ready. Regardless, this would be an amazing
> thing.
> 
> Let me know what you think.

It is not clear to me what actually you offer. Do you propose that
a) we do the major effort while you give us helping hand
b) you do the major effort while we give you helping hand

I tried to look on flatpack support some time ago and backed off.
The major problem is that LyX relies on lot of tools around in order
to work properly which either means lot of tools porting or sanboxing
issues of already ported ones. If you are flatpack expert then it's
doable but if you are LyX-er which should learn nitty gritty detail
for one-shot release of LyX it does not pay off.

So back to your question if you propose a) I am sceptical we do have
anyone in the team with time to get into details of snap packaging
to do all the work.

On the other hand if you offer b) then I am happy to help in the sense
of providing details of LyX rough corners we encounter for the snap,
commiting necessary changes into our codebase, and give it some testing
time on one ubuntu machine I have access to...

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


Re: LyX 2.4.0 (IM policy.xml ban on eps/pdf conversions)

2022-03-07 Thread Pavel Sanda
On Fri, Feb 04, 2022 at 10:36:57AM +, José Abílio Matos wrote:
> On Wednesday, 2 February 2022 21.45.40 WET Pavel Sanda wrote:
> > Jose, could I ask for pythonic help?
> > We would need a routine in configure.py which check whether to remove 
> > eps->png
> > conversion in case IM bans those conversions. That could be done this way by
> > checking return status of the conversion. In bash that would be something
> > like this:
> > 
> > echo '%!PS' > /tmp/.lyx_configure_test.eps
> > convert  /tmp/.lyx_configure_test.eps /tmp/.lyx_configure_test.png
> > if ! [ $? == 0 ] ; then
> >   # remove eps->png conversion from configure settings, i.e. set \converter
> > "eps" "png" "" "" fi
> > 
> > 
> > Completely different way would be mimicking what IM internally does with GS
> > when converting eps->png. I already checked little bit and unfortunately it
> > won't be oneliner if we want to get resolution right. But probably doable
> > with additional script of our own. Pavel
> 
> I will look into this in the weekend.
> 
> 
> At some point I will want to overhaul the configure.py script.
> The purpose is, among others, to simplify the code required to do this kind 
> of tests.
> 
> The test above is relatively easy to do.
> Something that I should, probably, take into account is the order of the 
> tests.
> 
> In the sense that if we different \convert lines we probably retain the 
> last...
> 

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


Re: LyX 2.3 and 2.4 have troubles displaying EPS images

2022-02-09 Thread Pavel Sanda
On Wed, Feb 09, 2022 at 09:06:40PM +0100, Thibaut Cuvelier wrote:
> If there is no counter-argument against this, I believe it would be the
> easiest solution overall. Otherwise, LyX could look after -1, -2 files,
> show one of them arbitrarily (say, the first one), and display a message to
> the user ("This image file contains several images, only the first one is
> being displayed"), but I'm not sure that would bring any value to the user
> (unless they have excellent knowledge of EPS, which is not the majority, I
> guess).

Isn't it possible to tell our Adobe friend to export the image in a more
sane way? In my experience the moment I start doing more fancy vector editing
in various editors, postscript rendering in latex shows all kinds of glitches
and export to pdf is the only robust solution.

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


Re: LyX 2.3 and 2.4 have troubles displaying EPS images

2022-02-09 Thread Pavel Sanda
On Wed, Feb 09, 2022 at 02:06:17AM +0100, Thibaut Cuvelier wrote:
> Do you have any trick to debug this further? For the LyX 2.3 issue, it
> might be a timeout for large EPS; for 2.4, I have no idea.

One thing which come to my mind - do you have set some limits on EPS size
in imagemagick config?
In linux you can find various policies like

etc  at /etc/ImageMagick-6/policy.xml.
Perhaps windows install of IM has some limits set?

I looked directly into .eps file and it has so strange binary
header that I am afraid to open it by ghostscript :)
The normal header seem to start at line 35 position 5546.

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


Re: LyX 2.4.0 (IM policy.xml ban on eps/pdf conversions)

2022-02-02 Thread Pavel Sanda
On Mon, Jan 24, 2022 at 11:32:42PM +0100, Pavel Sanda wrote:
> On Thu, Dec 02, 2021 at 10:24:58PM +0100, Pavel Sanda wrote:
> > - improve detection/users warning for banned eps->* conversion of 
> > imagemagick (high priority before final release, but not for next 
> > alpha/beta etc)
> 
> One option to automatically overcome the issue is to disable eps->png 
> conversion and allow pdf->png so that lyx performs eps->pdf->png.
> On my debian adding this to preferences sort of fixes the issue:
> 
> \converter "pdf6" "png" "pdftoppm -png -singlefile $$i >  $$o" ""
> \converter "eps" "png" "" ""
> 
> Problems I see:
> - the zoom factors in lyx window are not consistent with previous IM 
> conversion (you need to remove cache to test this)

I found out that IM uses by default DPI of 72 when calling GS so this problem 
is solved by using "pdftoppm -r 72 -png -singlefile $$i >  $$o"
Transparency is lost but I don't think that is a big deal.

> - not sure how is the pdftoppm conversion portable to windows/mac environment

Actually we have GS under our control for Win, not sure about Mac but mayb the 
IM policy is not to ban eps/pdf conversions.

> We could perhaps check policy.xml of IM and add those only in case eps/pdf is 
> banned when doing reconfigure.

Jose, could I ask for pythonic help?
We would need a routine in configure.py which check whether to remove eps->png 
conversion in case IM bans those conversions.
That could be done this way by checking return status of the conversion. In 
bash that would be something like this:

echo '%!PS' > /tmp/.lyx_configure_test.eps
convert  /tmp/.lyx_configure_test.eps /tmp/.lyx_configure_test.png
if ! [ $? == 0 ] ; then 
  # remove eps->png conversion from configure settings, i.e. set \converter 
"eps" "png" "" ""
fi


Completely different way would be mimicking what IM internally does with GS 
when converting eps->png. I already checked little bit and unfortunately it 
won't be oneliner if we want to get resolution right. But probably doable with 
additional script of our own.
Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Depth in/decrease used as equivalent to outline in/out

2022-02-02 Thread Pavel Sanda
On Tue, Feb 01, 2022 at 01:41:39PM +0100, Kornel Benko wrote:
> For me it is OK as it is now.
> 
> -1 to revert.

As Kornel I prefer the way it is now (except there might be some buggy corner 
cases
as you write in other mail, but in general I'm not confused by the current 
situation
and find nice that both cases are neatly covered by Tab). Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: SIGSEGV on master when exporting MergedManuals.lyx in GUI

2022-01-28 Thread Pavel Sanda
On Mon, Jan 24, 2022 at 11:07:38AM +0100, Pavel Sanda wrote:
> On Mon, Dec 27, 2021 at 10:01:12PM +0100, Jean-Marc Lasgouttes wrote:
> > Le 27/12/2021 ?? 19:53, Scott Kostyshak a écrit :
> > >>It is not that I am not interested, but rather that I am incompetent in
> > >>these things. Did someone look for subsequent commits in the lyx-unstable
> > >>tree?
> > >
> > >I took a quick look and did not see anything right after.
> > >
> > >I just compiled lyx-unstable and reproduce the bug on it (i.e., on
> > >branch "unstable").
> > 
> > Thanks for checking.
> 
> Given that we either can not reproduce the crash which should have been fixed
> nor we have clue how to fix the current one caused by the fix I'll revert 
> soon.

Done at 33c68d7750e.

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


Re: LyX 2.4.0 (IM policy.xml ban on eps/pdf conversions)

2022-01-24 Thread Pavel Sanda
On Thu, Dec 02, 2021 at 10:24:58PM +0100, Pavel Sanda wrote:
> - improve detection/users warning for banned eps->* conversion of imagemagick 
> (high priority before final release, but not for next alpha/beta etc)

One option to automatically overcome the issue is to disable eps->png 
conversion and allow pdf->png so that lyx performs eps->pdf->png.
On my debian adding this to preferences sort of fixes the issue:

\converter "pdf6" "png" "pdftoppm -png -singlefile $$i >  $$o" ""
\converter "eps" "png" "" ""

Problems I see:
- the zoom factors in lyx window are not consistent with previous IM conversion 
(you need to remove cache to test this)
- not sure how is the pdftoppm conversion portable to windows/mac environment


We could perhaps check policy.xml of IM and add those only in case eps/pdf is 
banned when doing reconfigure.

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


Re: SIGSEGV on master when exporting MergedManuals.lyx in GUI

2022-01-24 Thread Pavel Sanda
On Mon, Dec 27, 2021 at 10:01:12PM +0100, Jean-Marc Lasgouttes wrote:
> Le 27/12/2021 ?? 19:53, Scott Kostyshak a écrit :
> >>It is not that I am not interested, but rather that I am incompetent in
> >>these things. Did someone look for subsequent commits in the lyx-unstable
> >>tree?
> >
> >I took a quick look and did not see anything right after.
> >
> >I just compiled lyx-unstable and reproduce the bug on it (i.e., on
> >branch "unstable").
> 
> Thanks for checking.

Given that we either can not reproduce the crash which should have been fixed
nor we have clue how to fix the current one caused by the fix I'll revert soon.

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


Re: Status of Master?

2022-01-24 Thread Pavel Sanda
On Wed, Jan 05, 2022 at 12:25:00PM +, José Abílio Matos wrote:
> On Tuesday, 4 January 2022 10.56.51 WET Kornel Benko wrote:
> > There is one:
> > File 'preferences' is not updated, so I had to manually change occurrences
> > of 'python', 'python3' and 'python -tt' to '$${python}'.
> > 
> > The changed lines in preferences here:
> >  $ egrep python preferences
> > 
> > \converter "docbook5" "epub2" "$${python} $$s/scripts/docbook2epub.py java
> > none none none $$i $$o" ""
> > \converter "pygr" "eps" "$${python}  $$i  $$o" ""
> > \copier pdflatex "$${python} $$s/scripts/ext_copy.py -e pdf,aux -d $$i $$o"
> > 
> > Kornel
> 
> You raise a good point. What should we do with current preferences?
> I am not completly sure that you should do it automatically... Probably 
> checking for the canonical form "python -tt"?
> 
> If we decide to do it then probably the right path is add a new format and 
> change pref2pref.py in lib/scripts.
> 
> What is the general sentiment regarding this change in preferences?

I am not sure either. The conversion to $${python} would be probably
better, but given variety of python commands users can insert I am
not sure we can write robust conversion routine.

We could perhaps just detect "python" without and issue warning?

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


Re: SIGSEGV on master regarding math completion

2022-01-24 Thread Pavel Sanda
On Thu, Jan 20, 2022 at 09:40:21PM -0500, Scott Kostyshak wrote:
> > To reproduce:
> > 
> > 1. Start a new document.
> > 2. Ctrl + m to start math inset.
> > 3. Type \phantomx. Note that \phantomx is not a command so don't
> >expect it to be recognized.
> > 4. Press , ,  to delete the "x" and the "m".
> > 5. Type "m" to finish "phantom".
> > 6. Wait for the completion pop-down to appear (this takes a second).
> > 7. Press .
> > 
> > I tried to find a more simple recipe to reproduce but could not.
> > 
> > The result is that I get a SIGSEGV. Backtrace is attached.
> 
> Can anyone reproduce?

I can reproduce.

> I cannot reproduce on 2.3.0, but the 2.3.0 behavior is not ideal either.
> After (7) there's no crash but also the phantom inset is not created.
> That said, if it would be helpful for me to spend time on a bisect I
> don't mind.

That would be definitely helpful.

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


Re: [LyX/master] Add new placeholder $${python} to configure

2022-01-23 Thread Pavel Sanda
On Sun, Jan 23, 2022 at 04:06:07PM +, José Abílio Matos wrote:
> Could it be a cache interfering?
> Are the previewed files cached?

I don't think so. I also checked whether missing reconfigure could have been
the case, but it does not look like that either.
Last thing coming to my mind is that I was not working on master's HEAD but
few commits back when the $$(python) transition was not finished.

Who knows, I'll keep an eye on it.

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


Re: [LyX/master] Add new placeholder $${python} to configure

2022-01-23 Thread Pavel Sanda
On Sat, Jan 22, 2022 at 09:54:39PM +, José Abílio Matos wrote:
> The problem here is that the placeholder is not replaced before being used.
> In order to see what python is being used you can see:
> 
> Help->About LyX

python3 -tt

> In a hunch does the attached patch fixes the issue?
> The idea is to replace the placeholder when the converter is added/imported.

Strangely, I can't reproduce the problem anymore. I'll wait if I can catch it 
again.
Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Crash on master because of cursor position in session

2022-01-22 Thread Pavel Sanda
On Sat, Jan 22, 2022 at 09:43:15PM +0100, Pavel Sanda wrote:
> lyx::TextMetrics::redoParagraph:522 pm.rows() = breakParagraph(bigrow); -> 
> step into
> lyx::TextMetrics::breakParagraph:1136 tail = rb.shortenIfNeeded(width, 
> next_width); -> step into
> lyx::Row::shortenIfNeeded:640 if (cit->splitAt(w - wid, next_width, true, 
> tail)) {
> 
> ... (equivalently 4x cont on  Row.cpp:640 breakpoint and then step in)
> 
> Thread 1 "lyx" hit Breakpoint 5, lyx::Row::shortenIfNeeded 
> (this=0x588a7ae0, w=569, next_width=203) at Row.cpp:640
> 640 if (cit->splitAt(w - wid, next_width, true, tail)) {


Biset leads to:
commit d723b90344c0e56b26fc69aa00cb3001e074a723
Author: Jean-Marc Lasgouttes 
Date:   Mon Sep 6 14:52:42 2021 +0200

Break multi-row strings in one pass

Replace FontMetrics::breakAt, which returned the next break point,
with FontMetrics::breakString, which returns a vector of break points.
To this end, an additional parameter gives the available width for
next rows.

Rename various variables and methods accordingly. Factor the code in
breakString_helper to be more manageable.

Adapt Row::Element::splitAt to return a bool on sucess and provide
remaining row elements in a vector. The width noted above has been
added as parameters.

Rename the helper function splitFrom to moveElements and rewrite the
code to be more efficient.

Remove type of row element INVALID, which is not needed anymore.

The code in TextMetrics::breakParagraph is now much simpler.

In Row::finalize, remove the code that computed inconditionnally the
current element size, and make sure that this width will be computed
in all code paths of Row::Element::splitAt.

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


Re: Crash on master because of cursor position in session

2022-01-22 Thread Pavel Sanda
On Sun, Jan 16, 2022 at 12:02:50PM +0100, Kornel Benko wrote:
> Moreover, from then on the crash will always happen.
> Resetting the line in lyx2.4.conf from
>   zoom_ratio=1.9333
> to
>   zoom_ratio=1.0
> cured it.
> 
> Running under gdb, the software exception happens deep inside QT.
> (Not enough skills to find a workaround, sorry)

If you go step by step in gdb you'll see that last steps before the exceptions 
are:

lyx::TextMetrics::redoParagraph:522 pm.rows() = breakParagraph(bigrow); -> step 
into
lyx::TextMetrics::breakParagraph:1136 tail = rb.shortenIfNeeded(width, 
next_width); -> step into
lyx::Row::shortenIfNeeded:640 if (cit->splitAt(w - wid, next_width, true, 
tail)) {

... (equivalently 4x cont on  Row.cpp:640 breakpoint and then step in)

Thread 1 "lyx" hit Breakpoint 5, lyx::Row::shortenIfNeeded 
(this=0x588a7ae0, w=569, next_width=203) at Row.cpp:640
640 if (cit->splitAt(w - wid, next_width, true, tail)) {
(gdb) s
__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator > 
>, std::__debug::vector >, 
std::forward_iterator_tag>::operator-> (
this=0x7fffa840) at /usr/include/c++/10/debug/safe_iterator.h:314
314 _GLIBCXX_DEBUG_VERIFY(this->_M_dereferenceable(),
(gdb) n
317 return base().operator->();
(gdb) n
318   }
(gdb) 
Error: Software exception Detected

LyX has caught an exception, it will now attempt to save all unsaved documents 
and exit.

Exception: basic_string::substr: __pos (which is 32) > this->size() (which is 
31)


I do not know enough about row structure to inspect what's wrong with the 
variables.

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


Re: [LyX/master] Add new placeholder $${python} to configure

2022-01-22 Thread Pavel Sanda
On Tue, Jan 04, 2022 at 12:52:37AM +0100, JosĂŠ Matos wrote:
> commit 109ea2be4a21ca93d22ab25703b3352a50fbbe3b
> Author: José Matos 
> Date:   Tue Jan 4 00:21:34 2022 +
> 
> Add new placeholder $${python} to configure
> 
> This ensures that we use a consistent Python interpreter in LyX.
> 
> $${python} is replaced by the Python version found.
> 
> Users can apply this in preferences and use the same version defined by
> LyX.

Hi Jose,

this what I see in curent master:
1. start lyx 
2. load file
3. this is  what I see in terminal window:
env: '$${python}': No such file or directory

Most likely related to image preview conversions, this what I see with debug
messages on graphics:
graphics/PreviewLoader.cpp (757): PreviewLoader::finishedInProgress(127): 
processing failed for $${python} $$s/scripts/lyxpreview2bitmap.py --png 
"/tmp/lyx_tmpdir.LiGxsfYQmUxW/lyx_tmpbuf6/lyxpreviewGdodeo.tex" --dpi 115 --fg 
ff9822 --bg 00 --bibtex="bibtex"


These binaries available on my system:
python python2python2.7  python3python3.9
python defaults to python2.7

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


Re: Cross References in the Manuals/Help Files

2022-01-17 Thread Pavel Sanda
On Fri, Jan 14, 2022 at 07:25:31AM +0200, Dr Eberhard Lisse wrote:
> I came across the reference in the UserGuide to Program Listings in the
> Embedded Objects Manual, due to a recent thread, and noticed that that
> reference is not a (Clickable) Cross Reference.
> 
> Would making all those references cross references be worth of a
> request-for feature?
> 
> I realize the effort involved, as all those documents will need to
> be(come) Child Documents, which might be a good idea anyway, because
> then the whole manual can be printed as one.
> 
> And while considering it, would it be a good idea to ensure all of this
> works as DocBook so it can become a Handbook on Kindle?

I would not recommend to crosslink manuals into single large creature due
to it's fragility, but to have merged manuals in a single output is good.
Unfortunately its implementation is harder than it seems on the first sight.
You can have a look on  lib/doc/MergedManuals.lyx.

For LaTeX output manuals do have very different preambles which clash, xhtml 
output
looks pretty bad on some places (and IIRC currently freezes on 2.4), for docbook
I haven't tried but suspect the same.

> Perhaps with a little embellishment one could even publish this on
> Amazon for a Euro or two and that way generate some funds for the
> project.

My idea was to publish merged manual on wiki.lyx.org so the google searches
for relevant queries directly leads you to manual, but as said xhtml output
needs more love then it currently gets...

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


Re: Fwd: String/Bytes Problem in layout2layout.py

2022-01-03 Thread Pavel Sanda
On Mon, Jan 03, 2022 at 03:16:47PM +, José Abílio Matos wrote:
> If you want I can take care of that, in 2.4, and see if there are cases where 
> the conversion is missing.

Please do, I suffer from ophidiophobia.

> @Riki: is it possible to have a layout file such that the encoding is not 
> utf-8?

The original reports most likely downloaded layouts referred in our wiki
(https://wiki.lyx.org/Layouts/Layouts , LyXBook), so I guess that layout
encoding is not in our hands.

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


Re: Fwd: String/Bytes Problem in layout2layout.py

2022-01-03 Thread Pavel Sanda
On Mon, Jan 03, 2022 at 02:04:20PM +, José Abílio Matos wrote:
> Looking into further detail I would easily that the first part of the patch 
> is 
> correct (change "..." to b"...").
> 
> The second part where it changes sys.stdin to sys.stdin.buffer is probably 
> incorrect:
> 
> The similar code in 2.4 is:
> # Open files
> if options.input_file:
> source = open(options.input_file, 'rb')
> elif PY2:
> source = sys.stdin
> else:
> source = sys.stdin.buffer
> 
> if options.output_file:
> output = open(options.output_file, 'wb')
> elif PY2:
> output = sys.stdout
> else:
> output = sys.stdout.buffer
> 
> So this should be the right change, keep the previous form if PY2 (python 2 
> is 
> used) else use the new call.

If I get that right the part of the "..." -> b"..." should be committed to 2.4?

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


Re: Clone issue

2022-01-02 Thread Pavel Sanda
On Sat, Jan 01, 2022 at 07:11:38PM +0300, Baris Erkus wrote:
> 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

Both should work (and do work here).

> The error is
> 
> fatal: repository 'https://git.lyx.org/lyx.git/' not found

Something in your system transform git:// into https://
(which is not supposed to work).
Maybe it's your .gitconfig or something similar?

Anyway the unofficial git repo is the way out.

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


Re: Why do we add converters in frontends GuiPrefs.cpp?

2022-01-02 Thread Pavel Sanda
On Sat, Jan 01, 2022 at 02:05:03PM +0100, Jean-Marc Lasgouttes wrote:
> >Does any one knows why we are injecting these calls manually there?
> 
> These are forward search commands. These could probably be done in configure
> script instead.

Most likely my doing.
These are just suggestions in drop-down menu you can use or edit in
your settings. I do not see much merit in moving it to configure
(they are not automagically used).

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


Re: Status of Master?

2022-01-02 Thread Pavel Sanda
On Mon, Dec 27, 2021 at 11:29:08AM -0500, Richard Kimberly Heck wrote:
> Where do people think things are now? 

If Jose is close to finish ${python} patch it would be good to have it
in the release. I believe this will trigger bunch of changes needed
for various distro maintainers and we should get feedback rather soon.

But if that means waiting for next 4 weeks, I'd say lets move...

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


Fwd: String/Bytes Problem in layout2layout.py

2021-12-29 Thread Pavel Sanda
Jose,

are the proposed changes sensible?
I remember there were flowing similar patches to python codebase before.

Pavel
- Forwarded message from "Leo L. Schwab"  -

From: "Leo L. Schwab" 
To: Debian Bug Tracking System 
Subject: Bug#1002821: lyx-common: String/Bytes Problem in layout2layout.py

Package: lyx-common
Version: 2.3.6-1
Severity: normal
Tags: patch upstream
X-Debbugs-Cc: ew...@ewhac.org

Dear Maintainer,

Discovered this while trying to use Editorium's LyXBook modules.
layout2layout.py was konking out with "TypeError: cannot use a bytes
pattern on a string-like object."  After a bunch of debugging, I found
some strings in the script that hadn't been bytes-ified, which seemed to
fix the problem.  Patch attached.

Schwab


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-2-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lyx-common depends on:
ii  python3 3.9.8-1
ii  tex-common  6.17

Versions of packages lyx-common recommends:
ii  lyx  2.3.6-1

lyx-common suggests no packages.

-- no debconf information

--- /usr/share/lyx/scripts/layout2layout.py 2020-12-01 02:33:35.0 
-0800
+++ ./layout2layout.py  2021-12-29 01:04:59.614016427 -0800
@@ -484,8 +484,8 @@
 i += 1
 continue
 col  = match.group(2)
-if col == "collapsable":
-lines[i] = match.group(1) + "collapsible"
+if col == b"collapsable":
+lines[i] = match.group(1) + b"collapsible"
 i += 1
 continue
 
@@ -703,7 +703,7 @@
 # Insert the required number of arguments at the end of the style 
definition
 match = re_End.match(lines[i])
 if match:
-newarg = ['']
+newarg = [b'']
 # First the optionals (this is the required order pre 2.1)
 if opts > 0:
 if opts == 1:
@@ -1153,7 +1153,7 @@
 if latextype == b"item_environment" and label.lower() == 
b"counter_enumi":
 lines[labeltype_line] = 
re_LabelType.sub(b'\\1\\2\\3Enumerate', lines[labeltype_line])
 # Don't add the LabelCounter line later
-counter = ""
+counter = b""
 
 # Replace
 #
@@ -1227,12 +1227,12 @@
 if options.input_file:
 source = open(options.input_file, 'rb')
 else:
-source = sys.stdin
+source = sys.stdin.buffer
 
 if options.output_file:
 output = open(options.output_file, 'wb')
 else:
-output = sys.stdout
+output = sys.stdout.buffer
 
 if options.format > currentFormat:
 error("Format %i does not exist" % options.format);


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


Re: Looking for KDE testers (Re: [PATCH] allow to force backing store for display)

2021-12-27 Thread Pavel Sanda
On Sun, Dec 26, 2021 at 07:55:02PM +0100, Jean-Marc Lasgouttes wrote:
> Normally, if the theme is transparent, the workarea should blink.

No problem like this here. It must be very specific WM config.

> However, looking at the latest information on the bug report
> https://www.lyx.org/trac/ticket/12119
> it seems that the issue may be limited to the window manager Sway. If this
> is the case, I'd propose to remove the GUI for the lyxrc entry and just
> leave the variable for manual tweaking.

Agreed.

> Or I could change the tooltip to say: "select this if the display blinks.
> Note that performance may suffer and that subpixel aliasing will be
> disabled."

I would only keep the RC so we could easily ask for users to test,
but until it proves to be useful, this UI looks rather distracting.

Given that another transparent WMs can deal with this situation
isn't it also reasonable to ask affected users to file the bug
against their niche WM?

(I have access to KDE machine but when I started to look how to get
the Kvantum thing working I quickly backtracked. I really don't think
this will affect large mass of users, just because you can't just
click somewhere in preferences and have it on your machine.)

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


Re: SIGSEGV on master when exporting MergedManuals.lyx in GUI

2021-12-27 Thread Pavel Sanda
On Sun, Dec 26, 2021 at 11:06:54PM -0500, Scott Kostyshak wrote:
> > Anyway if no one is interested in understading underlying issue I would 
> > favour
> > reverting 65b674ba4eff of unknown crash than keeping known freeze :)
> 
> Thanks, Pavel. This seems like a tricky issue to debug.

If JMarc is not interested, let's just revert. Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: fsanitize: member access within null pointer

2021-12-27 Thread Pavel Sanda
On Sun, Dec 26, 2021 at 09:48:11AM +0100, Kornel Benko wrote:
> > I guess clang is not happy with (((struct sockaddr_un *) 0)->sun_path)
> > 
> > Our own code has:
> > #if !defined(SUN_LEN)
> > #define SUN_LEN(su) \
> > (sizeof (*(su)) - sizeof ((su)->sun_path) + strlen((su)->sun_path))
> > #endif
> 
> That was a good guess! With the attached change the message does not appear 
> anymore.

Apart from that error message is there some functional problem for LyX?
Otherwise I would leave things as they are, it's not our code and sooner
or later someone will report this to libc maintainers. (Or it could be
you? :)

Or add a comment once we forget...

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


Re: SIGSEGV on master when exporting MergedManuals.lyx in GUI

2021-12-26 Thread Pavel Sanda
On Sat, Dec 25, 2021 at 07:38:22PM +0100, Pavel Sanda wrote:
> On Fri, Nov 05, 2021 at 12:10:20AM -0400, Scott Kostyshak wrote:
> > On Wed, Apr 14, 2021 at 12:45:04PM -0400, Scott Kostyshak wrote:
> > > On Tue, Apr 13, 2021 at 07:53:11PM +0100, José Abílio Matos wrote:
> > > > On Tuesday, April 13, 2021 5:17:24 PM WEST Scott Kostyshak wrote:
> > > > > I get the following terminal messages followed by a SIGSEGV when 
> > > > > opening and
> > > > > viewing MergedManuals.lyx in the GUI:
> > > > > 
> > > > >   QSocketNotifier: Invalid socket 16 and type 'Read', disabling...
> > > > > 
> > > > > Does anyone else see this on master?
> > > > > 
> > > > > Scott
> > > > 
> > > > For me it is socket 10. :-)
> > > > 
> > > > LyX does not crash but it enters an infinite cycle (read that after 5 
> > > > minutes 
> > > > it continues to output that line) sending that line to stderr.
> > > > I am not sure if I am patient enough to wait for infinity before 
> > > > recovering 
> > > > LyX's control. :-)
> > > 
> > > Thanks for confirming, José.
> > 
> > I can still reproduce the infinite cycle (but not the original SIGSEGV) on 
> > master.

The infinite cycle can be reproduced by way simpler document.
1) Create master a and child b.
2) Put into child equation.
3) In master Document->Settings->Math Output->Images
4) View in XHTML.
5) Freeze in cycle QSocketNotifier: Invalid socket 16 and type 'Read', 
disabling...

I do not see the same problem in 2.3 and can confirm that reverting 65b674ba4eff
fixes the problem though I do not see straightforward connection between 
images creation and document childern business.

Anyway if no one is interested in understading underlying issue I would favour
reverting 65b674ba4eff of unknown crash than keeping known freeze :)


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


Re: SIGSEGV on master when exporting MergedManuals.lyx in GUI

2021-12-25 Thread Pavel Sanda
On Fri, Nov 05, 2021 at 12:10:20AM -0400, Scott Kostyshak wrote:
> On Wed, Apr 14, 2021 at 12:45:04PM -0400, Scott Kostyshak wrote:
> > On Tue, Apr 13, 2021 at 07:53:11PM +0100, José Abílio Matos wrote:
> > > On Tuesday, April 13, 2021 5:17:24 PM WEST Scott Kostyshak wrote:
> > > > I get the following terminal messages followed by a SIGSEGV when 
> > > > opening and
> > > > viewing MergedManuals.lyx in the GUI:
> > > > 
> > > >   QSocketNotifier: Invalid socket 16 and type 'Read', disabling...
> > > > 
> > > > Does anyone else see this on master?
> > > > 
> > > > Scott
> > > 
> > > For me it is socket 10. :-)
> > > 
> > > LyX does not crash but it enters an infinite cycle (read that after 5 
> > > minutes 
> > > it continues to output that line) sending that line to stderr.
> > > I am not sure if I am patient enough to wait for infinity before 
> > > recovering 
> > > LyX's control. :-)
> > 
> > Thanks for confirming, José.
> 
> I can still reproduce the infinite cycle (but not the original SIGSEGV) on 
> master.

I can see SIGSEGV, but only in case I run the instance under GDB (the app does 
not crash,
I think because it happens only in additional thread). 

.
Backtrace:
[Switching to Thread 0x7fffe8f1c700 (LWP 230667)]
0x56478e0f in lyx::Buffer::listMacroNames (this=0x0, macros=...) at 
Buffer.cpp:3915
3915if (d->macro_lock)
(gdb) bt
#0  0x56478e0f in lyx::Buffer::listMacroNames (this=0x0, macros=...) at 
Buffer.cpp:3915
#1  0x568f403a in lyx::InsetMathHull::preparePreview 
(this=0x585d51d0, pos=..., forexport=true)
at mathed/InsetMathHull.cpp:814
#2  0x568f4f4f in lyx::InsetMathHull::loadPreview (this=0x585d51d0, 
pos=...) at mathed/InsetMathHull.cpp:878
#3  0x569001cd in lyx::InsetMathHull::xhtml[abi:cxx11](lyx::XMLStream&, 
lyx::OutputParams const&) const (this=0x585d51d0, 
xs=..., op=...) at mathed/InsetMathHull.cpp:2682
#4  0x566e3da7 in 
lyx::Paragraph::simpleLyXHTMLOnePar[abi:cxx11](lyx::Buffer const&, 
lyx::XMLStream&, lyx::OutputParams const&, l

yx::Font const&, bool, bool, long) const (this=0x5832f940, buf=..., xs=..., 
runparams=..., outerfont=..., start_paragraph=true, 
close_paragraph=true, initial=0) at Paragraph.cpp:3986
#5  0x566cd6c6 in lyx::(anonymous namespace)::makeParagraphs (buf=..., 
xs=..., runparams=..., text=..., pbegin=
  {itemdepth = 0 '\000', d = 0x5832f960}, pend={itemdepth = 1 '\001', d = 
0x0}) at output_xhtml.cpp:345
#6  0x566cf6b6 in lyx::xhtmlParagraphs (text=..., buf=..., xs=..., 
runparams=...) at output_xhtml.cpp:667
#7  0x56b5151e in 
lyx::InsetText::insetAsXHTML[abi:cxx11](lyx::XMLStream&, lyx::OutputParams 
const&, lyx::InsetText::XHTMLOptions

) const (this=0x5832f840, xs=..., rp=..., opts=lyx::InsetText::JustText) at 
insets/InsetText.cpp:863
#8  0x56b1b2a2 in 
lyx::InsetTableCell::xhtml[abi:cxx11](lyx::XMLStream&, lyx::OutputParams 
const&) const (this=0x5832f840, 
xs=..., rp=...) at insets/InsetTabular.cpp:4317
#9  0x56b174d3 in lyx::Tabular::xhtmlRow[abi:cxx11](lyx::XMLStream&, 
unsigned long, lyx::OutputParams const&, bool) const (
this=0x58329330, xs=..., row=8, runparams=..., header=false) at 
insets/InsetTabular.cpp:3847
#10 0x56b18533 in lyx::Tabular::xhtml[abi:cxx11](lyx::XMLStream&, 
lyx::OutputParams const&) const (this=0x58329330, xs=..., 
runparams=...) at insets/InsetTabular.cpp:3930
#11 0x56b24b0a in lyx::InsetTabular::xhtml[abi:cxx11](lyx::XMLStream&, 
lyx::OutputParams const&) const (this=0x58329320, 
xs=..., rp=...) at insets/InsetTabular.cpp:6189
#12 0x566e3da7 in 
lyx::Paragraph::simpleLyXHTMLOnePar[abi:cxx11](lyx::Buffer const&, 
lyx::XMLStream&, lyx::OutputParams const&, l

yx::Font const&, bool, bool, long) const (this=0x58329050, buf=..., xs=..., 
runparams=..., outerfont=..., start_paragraph=true, 
close_paragraph=true, initial=0) at Paragraph.cpp:3986
#13 0x566cd6c6 in lyx::(anonymous namespace)::makeParagraphs (buf=..., 
xs=..., runparams=..., text=..., pbegin=
  {itemdepth = 0 '\000', d = 0x583282b0}, pend={itemdepth = 3 '\003', d = 
0x0}) at output_xhtml.cpp:345
#14 0x566cf6b6 in lyx::xhtmlParagraphs (text=..., buf=..., xs=..., 
runparams=...) at output_xhtml.cpp:667
#15 0x56b51af4 in 
lyx::InsetText::insetAsXHTML[abi:cxx11](lyx::XMLStream&, lyx::OutputParams 
const&, lyx::InsetText::XHTMLOptions

) const (this=0x583280a0, xs=..., rp=..., opts=6) at 
insets/InsetText.cpp:899
#16 0x56a2e4ca in lyx::InsetFloat::xhtml[abi:cxx11](lyx::XMLStream&, 
lyx::OutputParams const&) const (this=0x583280a0, 
xs=..., 

Re: LyX 2.4.0

2021-12-25 Thread Pavel Sanda
On Sun, Dec 05, 2021 at 12:43:30PM -0500, Richard Kimberly Heck wrote:
> >1. Reverting the behavior that changes a missing child from an error to
> >a warning (you can see discussion here:
> >
> > https://www.mail-archive.com/search?l=mid=20210416164324.gnegtimfws37hhma%40tallinn).
> >If I remember correctly, it's not just a simple revert, although I
> >forgot the details. In any case, I just need to find time to work on
> >it and revert it and run through a variety of situations.
> 
> >3. LyX's configure should not assume 'python' command exists.
> >
> > (https://www.mail-archive.com/search?l=mid=20210215004347.vha7nygqpd6g5h5q%40tallinn)
> 
> I've asked Pavel to create a wiki to-do list. Or you can do it. ;-) All such
> things can be added.

I put the two above on the wiki, not sure about their phase (alpha->beta 
stage?).

I think for clear advancement every point should have someone in charge.
In case of python that is Jose?

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


Re: LyX 2.4.0

2021-12-25 Thread Pavel Sanda
On Sun, Dec 05, 2021 at 12:42:24PM -0500, Richard Kimberly Heck wrote:
> Pavel, can you make a wiki page that's a to-do list for 2.4.0?

I cloned older wiki page, you can change it as you see fit.
https://wiki.lyx.org/Devel/LyX24Road

I put there my bullet points, other devs please fill up you issues,
we can use this page to see up-to-date blockers for the release.

Riki, you might want to update Dates of release plans, but given the
current situation you might just want to delete that section :)

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


Re: fsanitize: member access within null pointer

2021-12-25 Thread Pavel Sanda
On Thu, Dec 16, 2021 at 04:35:39PM +0100, Kornel Benko wrote:
> As strings:
> (gdb) x/10s 
> 0x7fffd788:   "\001"
> 0x7fffd78a:   "/tmp/lyx_tmpdir.kVhnZYL31128/lyxsocket"
> 0x7fffd7b1:   ""
> 0x7fffd7b2:   ""
> 0x7fffd7b3:   ""
> 0x7fffd7b4:   ""
> 0x7fffd7b5:   ""
> 0x7fffd7b6:   ""
> 0x7fffd7b7:   ""
> 0x7fffd7b8:   "|"
> (gdb) 

This looks fine.

Maybe it's because SUN_LEN macro.

In my system I see in /usr/include/x86_64-linux-gnu/sys/un.h
# define SUN_LEN(ptr) ((size_t) (((struct sockaddr_un *) 0)->sun_path)\
  + strlen ((ptr)->sun_path))


I guess clang is not happy with (((struct sockaddr_un *) 0)->sun_path)

Our own code has:
#if !defined(SUN_LEN)
#define SUN_LEN(su) \
(sizeof (*(su)) - sizeof ((su)->sun_path) + strlen((su)->sun_path))
#endif

which does not have this constrt and clang might be happier.
I do not known what headers gets included with clang though.

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


Re: Looking for KDE testers (Re: [PATCH] allow to force backing store for display)

2021-12-23 Thread Pavel Sanda
On Fri, Dec 17, 2021 at 03:25:47PM +0100, Jean-Marc Lasgouttes wrote:
> I would be grateful of a KDE/X11 user could try to install a translucid
> windows theme like Layan and check
> 1/ that it creates display issues
> 2/ that the new checkbox in Preferences|Display fixes it (at the cost of
> losing subpixel aliasing).

I don't have KDE but I have X11 WM with transparent theme, what exactly should 
I do?
Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Lyx Mirror in Iran

2021-12-23 Thread Pavel Sanda
On Thu, Dec 23, 2021 at 01:26:44PM +0330, BardiW wrote:
>- Country: Iran
>- Hosted by: https://bardia.tech
>- Contact Name: Bardia Moshiri
>- Contact Email: fakesh...@bardia.tech
>- HTTP: http://mirror.bardia.tech/repo/lyx
>- HTTPS: https://mirror.bardia.tech/repo/lyx
>- Bandwidth:1000Mbps

Added, thanks!
Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: fsanitize: member access within null pointer

2021-12-16 Thread Pavel Sanda
On Thu, Dec 16, 2021 at 01:47:50PM +0100, Kornel Benko wrote:
> Am Thu, 16 Dec 2021 13:38:43 +0100
> schrieb Pavel Sanda :
> 
> > On Tue, Dec 07, 2021 at 10:20:02PM -0500, Scott Kostyshak wrote:
> > > Compiling master with Clang and fsanitize, I get the following when
> > > LyX starts up (without doing anything else):
> > > 
> > >   /home/scott/lyxbuilds/master/repo/src/support/socktools.cpp:114:56: 
> > > runtime error:
> > > member access within null pointer of type 'struct sockaddr_un'
> > > 
> > > Can anyone take a look?  
> > 
> > Does changing sockaddr -> sockaddr_un in the critical line changes 
> > anything? P
> 
> /usr2/src/lyx/lyx-git/src/support/socktools.cpp:114:19: error: cannot 
> initialize a
> parameter of type 'const struct sockaddr *' with an rvalue of type 
> 'sockaddr_un *'
> if ((::bind (fd, reinterpret_cast(), 
> SUN_LEN())) == -1) {
>  ^~
> /usr/include/x86_64-linux-gnu/sys/socket.h:112:49: note: passing argument to 
> parameter
> '__addr' here extern int bind (int __fd, __CONST_SOCKADDR_ARG __addr, 
> socklen_t __len)

Can you setup breakpoint on the critical line and display the content of addr? P
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: fsanitize: member access within null pointer

2021-12-16 Thread Pavel Sanda
On Tue, Dec 07, 2021 at 10:20:02PM -0500, Scott Kostyshak wrote:
> Compiling master with Clang and fsanitize, I get the following when
> LyX starts up (without doing anything else):
> 
>   /home/scott/lyxbuilds/master/repo/src/support/socktools.cpp:114:56: runtime 
> error: member access within null pointer of type 'struct sockaddr_un'
> 
> Can anyone take a look?

Does changing sockaddr -> sockaddr_un in the critical line changes anything? P
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Enable editing in preview pane for "LyX" format?

2021-12-15 Thread Pavel Sanda
On Wed, Dec 15, 2021 at 10:13:33AM -0500, Scott Kostyshak wrote:
> We have the option to show the LyX format in the preview window. We also
> have the functionality to reload a LyX document (e.g., if it is changed
> externally). Would it be reasonable to allow editing of the LyX format
> in the preview window?
> 
> It seems feasible to implement, but I think the main question is whether
> it would actually be useful and I'm not sure.

How are you going to guard against crashes when reloading wrong data?
Pavel

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


Re: Cursor stuck ahead of footnote in 2.4

2021-12-15 Thread Pavel Sanda
On Wed, Dec 15, 2021 at 11:33:11AM +0100, Jean-Marc Lasgouttes wrote:
> This seems fixed by the fix to the other problem. Can you confirm?

Looks good here. Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Cursor stuck ahead of footnote in 2.4

2021-12-13 Thread Pavel Sanda
Hi,

- open user guide in 2.4
- go to the beginning of the document
- hold arrow down on your keyboard

Cursor gets stuck at the line ahead of footnote 1 and does not move
downwards anymore.

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


Re: LyX 2.4.0

2021-12-04 Thread Pavel Sanda
On Fri, Dec 03, 2021 at 07:23:55AM +0100, Jürgen Spitzmüller wrote:
> Am Donnerstag, dem 02.12.2021 um 22:24 +0100 schrieb Pavel Sanda:
> > - recent toc_ related crashes (thread from Mon Nov  1 14:24:46 202;
> > we have Juergen's patch, but there might other pending issues I would
> > like to review). At least JS patch should go in before any new
> > release.
> 
> I have this patch on hold. Just tell me when/if this is needed or not,
> and I push the button.

Please go on, I'll try to return to it later. Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


  1   2   3   4   5   6   7   8   9   10   >