Re: Layout file format change proposal

[Lorenzo Bertini]

Dear devs,
thanks to everyone who chimed in. I didn't understand José's reply
until I looked at the lexers we use and found only one. I just didn't
occur to me that most files LyX uses are in this same format,
documents and configurations alike. This is a considerable advantage
of LyX's own format, and made me rethink my proposal.

Indeed it would make sense, if we have to change, to choose only one
format. But in my opinion, the best option for documents would be XML,
contrary to what so far we discussed about configuration files.
Perhaps it's best to leave things as they are.

Just out of curiosity I've tried converting a LyX document to YAML and
XML to see how they would look.

LYX:

\lyxformat 620
\begin_document
\begin_header
\language italian
\language_package default
\inputencoding utf8
\fontencoding auto
\font_roman "default" "default"
\font_sf_scale 100 100
\end_header
\begin_body
\begin_layout Title
LyX is a great editor
\end_layout
\begin_layout Author
Lorenzo
\end_layout
\begin_layout Section
Why LyX is great
\end_layout
\begin_layout Standard
\SpecialChar LyX
 can write
\series bold
equations
\series default
 like this with a nice editor
\begin_inset Formula
\[
(i\hbar\gamma^{\mu}\partial_{\mu}-mc)\psi(x)=0
\]
\end_inset
\end_layout
\begin_layout Section
Lyx is the best
\end_layout
\begin_layout Standard
Lyx can make
\emph on
tables
\emph default
 and
\emph on
figures
\emph default
.
\begin_inset Float figure
placement document
alignment document
wide false
sideways false
status collapsed
\begin_layout Plain Layout
\begin_inset Graphics
filename empty.png
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset Caption Standard
\begin_layout Plain Layout
Example image
\end_layout
\end_inset
\end_layout
\end_inset
\end_layout
\end_body
\end_document

YAML:

document:
  header:
language: italian
language_package: default
inputencoding: utf8
fontencoding: auto
font_roman: [default, default]
font_sf_scale: [100, 100]
  body:
- Title: "LyX is a great editor"
- Author: "Lorenzo"
- Section: "Why LyX is great"
  Standard: |
"LyX can write **equations** like this with a nice editor"
"\\[ (i\hbar\gamma^{\mu}\partial_{\mu}-mc)\psi(x)=0 \\]"
- Section: "Lyx is the best"
  Standard: |
"Lyx can make *on* tables *default* and *on* figures *default*."
  Float_figure:
placement: document
alignment: document
wide: false
sideways: false
status: collapsed
Plain_Layout:
  - Graphics:
  filename: empty.png
  - Caption: "Example image"

XML:


  
italian
default
utf8
auto

  default
  default


  100
  100

  
  
LyX is a great editor
Lorenzo
Why LyX is great
  LyX can write equations like this with a
nice editor
(i\hbar\gamma^{\mu}\partial_{\mu}-mc)\psi(x)=0
  

Lyx is the best
  Lyx can make on tables
default and on figures default.

  document
  document
  false
  false
  collapsed
  

  empty.png

Example image
  

  

  


More informations about the XML structure can be found in the wiki
page about the hypothetical transition. I updated it with some
examples and things yet to determine.

Thanks to everyone that contributed to this discussion. It was insightful.

Lorenzo.

Il giorno ven 5 apr 2024 alle ore 11:52 José Matos
 ha scritto:
>
> On Thu, 2024-03-28 at 13:00 +0100, Thibaut Cuvelier wrote:
> > All of these formats are rather well supported and far from shiny new
> > things (I think all of them have at least a decade of existence).
> >
> > Regarding validation: XML Schema has many offsprings, such as JSON
> > Schema (https://json-schema.org/), with implementations that work on
> > YAML and TOML (https://json-schema-everywhere.github.io/toml). In any
> > case, these schemas are extremely lacking compared to 21st-century
> > XML validation (RelaxNG with Schematron).
> > We currently have no validation, but it would be great to have it as
> > part of the test suite.
> >
> > How well do these formats work with (long) strings? What's great with
> > the current format is that you don't need to escape anything when LyX
> > expects a string. This aspect of the design removes a huge source of
> > typos.
>
> I agree with Thibaut's analysis.
>
> In addition I would say that with all its faults the upgrade mechanism
> between the different file formats is well defined and streamlined,
> note for example the number of LyX file formats that we have (more than
> 100).
>
> And this is also the part that lead us to the elephant in the room, the
> LyX file format where most of these discussions took place.
>
> IMHO it only makes sense to choose a file format if the purpose is to
> change all the different file formats to that model:
>
> * bind (key 

Re: Layout file format change proposal

[Lorenzo Bertini]

PS.

Reading JMarc comment under https://www.lyx.org/trac/ticket/13035 made
me think. I don't want to come off as suffering from "shiny new thing
syndrome". I am proposing this because I've had people tell me layouts
are "advanced", and one of the roadblocks to using LyX. Having easy
tools to edit them would help.

Also, provided some guidance, I volunteer to do the work necessary for this.

Lorenzo

Il giorno gio 28 mar 2024 alle ore 12:40 Lorenzo Bertini
 ha scritto:

>
> Il giorno gio 28 mar 2024 alle ore 11:40 José Matos
>  ha scritto:
> >
> > On Wed, 2024-03-27 at 11:02 -0400, Scott Kostyshak wrote:
> > > Cool idea, Lorenzo! There have been some discussions in the past on
> > > using standard formats, even for the .lyx file itself. I can see the
> > > advantages of that but I don't know what the cost of converting to
> > > them
> > > is.
> > >
> > > Scott
> >
> > Typical answer to this:
> > https://xkcd.com/927/
> >
> > :-)
> >
> > It makes sense for us to use a standard format.
> > Some of the questions then are:
> >  * which one is chosen (what is the most appropriate for our needs)?
> >  * what the are advantages and drawbacks from this change?
> >  * what is the transition plan?
> >  * what is the effort required for this transition?
> >
> > Best regards,
> > --
> > José Abílio
> > --
>
> Ah, a classic xkcd. For once, however, the talk is about "removing"
> one standard :)
>
> * Which one to choose?
> See research below.
>
> * The advantages and drawbacks
> As already mentioned, using a more common format means
>   - people generally more familiar with the format
>   - having more tools able to produce them, easing the efforts of
> publishers trying to provide layouts
>   - having parsers already available, for LyX and for people wanting
> to manipulate them externally
> The drawbacks that i can think of are
>   - migration always takes developer effort
>   - migration can take user effort too, to adapt to the new format
> (this can be greatly mitigated by which format is chosen)
>
> * The transition plan:
> The new format is introduced *alongside* the old format. The LyX
> version that brings the format will have all layouts converted, but
> will accept the old format too. This "transition period" can last
> indefinitely.
>
> * The efforts required for the transition
> We need to:
>   - write or choose a parser for the new format that maps a file to a
> LyX's params
>   - write a converter from the old format to the new one
>   - convert all the files to the new formats and test them
>
> Here is some info I dug up regarding configuration formats. For pros
> and cons I tried to limit them to one single aspect where they excel
> or fail
> - JSON:
>   . pros: most widely supported
>   . cons: not concise or readable, very distant from .layout
> - TOML:
>   . pros: very easy to read and write, even for humans
>   . cons: not widespread, distant from .layout
> - YAML:
>   . pros: very easy to read and write, very close to .layout
>   . cons: indentation is prone to syntax errors
> - XML:
>   . pros: the one and only, supports validation through schemas,
> widely supported
>   . cons: hard to read and write, very distant from .layout
>
> I asked a chatbot to convert LyX's following layout extract into those 
> formats:
>
> LYX'S LAYOUT
>
> InsetLayout Marginal
> LabelString   Margin
> LatexType command
> Font
>   SizeSmall
> EndFont
> LabelFont
>   Color   marginlabel
>   SizeSmall
> EndFont
> HTMLStyle
> div.marginal {
> border: 2px solid black;
> font-style: normal;
> }
> EndHTMLStyle
> End
>
> JSON:
>
> {
>   "InsetLayout": {
> "LabelString": "Margin",
> "LatexType": "command",
> "Font": {
>   "Size": "Small"
> },
> "LabelFont": {
>   "Color": "marginlabel",
>   "Size": "Small"
> },
> "HTMLStyle": {
>   "div.marginal": {
> "border": "2px solid black",
> "font-style": "normal"
>   }
> }
>   }
> }
>
> TOML:
>
> [InsetLayout]
>   LabelString = "Margin"
>   LatexType = "command"
>
>   [InsetLayout.Font]
> Size = "Small"
>
>   [InsetL

Re: Layout file format change proposal

[Lorenzo Bertini]

Il giorno gio 28 mar 2024 alle ore 11:40 José Matos
 ha scritto:
>
> On Wed, 2024-03-27 at 11:02 -0400, Scott Kostyshak wrote:
> > Cool idea, Lorenzo! There have been some discussions in the past on
> > using standard formats, even for the .lyx file itself. I can see the
> > advantages of that but I don't know what the cost of converting to
> > them
> > is.
> >
> > Scott
>
> Typical answer to this:
> https://xkcd.com/927/
>
> :-)
>
> It makes sense for us to use a standard format.
> Some of the questions then are:
>  * which one is chosen (what is the most appropriate for our needs)?
>  * what the are advantages and drawbacks from this change?
>  * what is the transition plan?
>  * what is the effort required for this transition?
>
> Best regards,
> --
> José Abílio
> --

Ah, a classic xkcd. For once, however, the talk is about "removing"
one standard :)

* Which one to choose?
See research below.

* The advantages and drawbacks
As already mentioned, using a more common format means
  - people generally more familiar with the format
  - having more tools able to produce them, easing the efforts of
publishers trying to provide layouts
  - having parsers already available, for LyX and for people wanting
to manipulate them externally
The drawbacks that i can think of are
  - migration always takes developer effort
  - migration can take user effort too, to adapt to the new format
(this can be greatly mitigated by which format is chosen)

* The transition plan:
The new format is introduced *alongside* the old format. The LyX
version that brings the format will have all layouts converted, but
will accept the old format too. This "transition period" can last
indefinitely.

* The efforts required for the transition
We need to:
  - write or choose a parser for the new format that maps a file to a
LyX's params
  - write a converter from the old format to the new one
  - convert all the files to the new formats and test them

Here is some info I dug up regarding configuration formats. For pros
and cons I tried to limit them to one single aspect where they excel
or fail
- JSON:
  . pros: most widely supported
  . cons: not concise or readable, very distant from .layout
- TOML:
  . pros: very easy to read and write, even for humans
  . cons: not widespread, distant from .layout
- YAML:
  . pros: very easy to read and write, very close to .layout
  . cons: indentation is prone to syntax errors
- XML:
  . pros: the one and only, supports validation through schemas,
widely supported
  . cons: hard to read and write, very distant from .layout

I asked a chatbot to convert LyX's following layout extract into those formats:

LYX'S LAYOUT

InsetLayout Marginal
LabelString   Margin
LatexType command
Font
  SizeSmall
EndFont
LabelFont
  Color   marginlabel
  SizeSmall
EndFont
HTMLStyle
div.marginal {
border: 2px solid black;
font-style: normal;
}
EndHTMLStyle
End

JSON:

{
  "InsetLayout": {
"LabelString": "Margin",
"LatexType": "command",
"Font": {
  "Size": "Small"
},
"LabelFont": {
  "Color": "marginlabel",
  "Size": "Small"
},
"HTMLStyle": {
  "div.marginal": {
"border": "2px solid black",
"font-style": "normal"
  }
}
  }
}

TOML:

[InsetLayout]
  LabelString = "Margin"
  LatexType = "command"

  [InsetLayout.Font]
Size = "Small"

  [InsetLayout.LabelFont]
Color = "marginlabel"
Size = "Small"

  [InsetLayout.HTMLStyle.div.marginal]
border = "2px solid black"
font-style = "normal"

YAML:

InsetLayout:
  LabelString: Margin
  LatexType: command
  Font:
Size: Small
  LabelFont:
Color: marginlabel
Size: Small
  HTMLStyle:
div.marginal:
  border: 2px solid black
  font-style: normal

XML:


  Margin
  command
  
Small
  
  
marginlabel
Small
  
  

  2px solid black
  normal

  


Obviously there are errors because it considered the CSS inside it as
part of the format. But I hope this gives you an impression of what
each format can give us. Personally, and for what it counts (very
little), my pick would the the closest to the original format, and
that would be YAML.

Let me know what you think.
Lorenzo
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Layout file format change proposal

[Lorenzo Bertini]

Dear devs,
I don't know if this has been discussed before. Lyx uses it's own
format .layout (or .module), with it's own parser. However, the same
information can be easily saved stored in another format. I asked a
chatbot to convert "amsbook.layout" to an hypothetical "amsbook.yaml"
file:

format: 104
columns: 1
sides: 2
page_style: Headers
docbook_root: book
provides:
  - amsmath: 1
  - makeidx: 1
class_options:
  font_size: [8, 9, 10, 11, 12]
default_modules:
  - theorems-ams
  - eqs-within-sections
  - figs-within-sections
styles:
  Standard:
category: MainText
margin: Static
latex_type: Paragraph
latex_name: dummy
par_indent: MM
par_skip: 0.4
align: Block
align_possible: [Block, Left, Right, Center]
label_type: No_Label
docbook_tag: para
preamble: "\numberwithin{section}{chapter}"
inputs:
  - stdsections.inc
  - stdinsets.inc
  - numreport.inc
  - lyxmacros.inc
  - stdlayouts.inc
  - stdlists.inc
  - stdfloats.inc
  - stdcounters.inc
  - amsdefs.inc
unwanted_styles:
  - Verse
  - Bibliography:
  toc_level: 0
styles_append:
  Section:
align: Center
font:
  series: Bold
  size: Large
toc_level: 1
  Subsection:
font:
  series: Bold
  size: Normal
toc_level: 2
  Subsubsection:
font:
  shape: Italic
  size: Normal
toc_level: 3
  Section*:
align: Center
font:
  series: Bold
  size: Large
  Subsection*:
font:
  series: Bold
  size: Normal
  Subsubsection*:
font:
  shape: Italic
  size: Normal
  Paragraph:
font:
  series: Medium
toc_level: 4
  Chapter_Exercises:
margin: First_Dynamic
latex_type: Item_Environment
latex_name: lyxxcb
next_no_indent: 1
left_margin: MMN
label_sep: xx
par_skip: 0.0
item_sep: 0.2
top_sep: 0.7
bottom_sep: 0.7
par_sep: 0.3
align: Block
align_possible: [Block, Left]
label_type: Itemize
label_font:
  shape: Up
  series: Bold
preamble: "\newenvironment{lyxxcb}..."
argument_listpreamble:
  - label_string: "List preamble"
menu_string: "List Preamble"
tooltip: "LaTeX code to be inserted before the first item"
pass_thru: 1
font:
  family: typewriter
  color: latex
docbook_tag: para
docbook_attr: role='chapter-exercises'

I think it looks pretty good. The advantages of using an industry standard are:
1. People already know the format. This could encourage publishers to
provide layouts.
2. Existing and solid tools for parsing can be used. Even if not
directly by LyX, someone manipulating layouts externally doesn't need
to reinvent the wheel.

Let me know what you think.

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

Re: Don't record (de)activating change tracking on undo stack

[Lorenzo Bertini]

Il giorno gio 30 nov 2023 alle ore 15:47 Jean-Marc Lasgouttes
 ha scritto:
>
> Le 30/11/2023 à 03:01, Daniel a écrit :
> > LyX has the peculiarity of treating the (de)activating of change
> > tracking as something that is recorded on the undo stack.
>
> Actually, everything that is stored in the file goes to the undo stack.
> I do not see how to avoid that.
>
> > One of the problems I ran into with this is that it unexpectedly killed
> > the redo function when I activated change tracking, i.e. I undid some
> > changes and activated the change tracking in between and this changed
> > what could be redone.
> >
> > The only other app I know of that does this is Apple Pages. But I am not
> > sure whether Apple's change tracking should be taken as a thought
> > through feature, e.g. it is impossible to de-activate change tracking
> > without accepting all changes. Go figure!
>
> Do other applications save change tracking status?
>
> Would you find it good that, if you open a file for the explicit purpose
> of setting change tracking "on", then it will be necessary to fake
> another change for the purpose of being able to save it? Or that undoing
> all your changes may leave certain change unbeknownst to you?
>
> There might be another way to avoid killing the redo stack. Do you know
> of any applicaiton that has a solution to this?
>
> JMarc

I agree with Daniel, it caught me off guard the first time that
document settings got in the way of undo-redo. Can't really tell what
other word processors use, but what I expected was that undo-redo only
applied to the text of the document. However, JMarc's point about not
being able to save after a setting change is very valid. If anyone has
libreoffice installed, how is this handled there?

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

Re: flatpak

[Lorenzo Bertini]

Il giorno ven 24 nov 2023 alle ore 18:24 T Rex  ha scritto:
>
> good day everyone, my apologies in advance if this is not the correct channel 
> to do the following: as Lyx is not available on flathub, I would like to 
> create the manifest so that it is available there, in any case the original 
> sources are used, is there any Problem with performing that action?
> --
> lyx-devel mailing list
> lyx-devel@lists.lyx.org
> http://lists.lyx.org/mailman/listinfo/lyx-devel

Not a dev, just wanted to chime in to say that i would be cool to have
an officially supported flatpak, as to have the checkmark on flathub.
Relevant bugtracker ticket from a year ago
https://www.lyx.org/trac/ticket/11143. If you manage to get a flatpak
working it could be a starting point.

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

Re: Beta 5 Tarballs

[Lorenzo Bertini]

Il 31/08/23 18:31, Jean-Marc Lasgouttes ha scritto:

Le 31/08/2023 à 17:35, Scott Kostyshak a écrit :

What does the Qt client-side decoration look like? I've only used LyX
briefly (just to test) on Ubuntu Wayland, but I'm surprised my picky
eyes didn't notice.

Also, JMarc. Do you get the same whether you build with Qt 5 or Qt 6?
I've tested building both on Ubuntu 23.04 with Wayland and everything
went smoothly. But I didn't check the appearance.


Here is what I get. I hate in particular how the title bar has no border 
nor shadow.


JMarc





Qt5 or Qt6 should only change whether you get the message


qt.qpa.wayland: Wayland does not support QWindow::requestActivate()


The ugly decorations should happen with both versions and are Qt's own 
client side decorations, a thing called "bradient". It is never 
mentioned in documentation, that's its name in the code. I must admit, 
it looks poor, and it lacks shadows on gnome because mutter (GNOME) 
leaves shadow creation (as everything else) to the application.


I think Qt devs created this to be a barebone client side decorations, 
and assumed the window manager would replace it with it's own. 
Surprising, considering mutter doesn't do this and it's one of the most 
used compositor/wm.


I've had this problem for some time, and I believe I've asked about this 
on the list. So far it seems up to the Qt devs.


--
lorenzo

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

Re: File nl.po does not exist

[Lorenzo Bertini]

Il 15/06/23 15:09, Pavel Sanda ha scritto:

On Thu, Jun 15, 2023 at 12:19:24PM +0200, Lorenzo Bertini wrote:

Dear list,

I can't build master anymore. It says:


make[3]: ??ja.gmo?? is up to date.
make[3]: ??nb.gmo?? is up to date.
make[4]: entering directory ??.../lyx/po??
File nl.po does not exist. If you are a translator, you can create it through 
'msginit'.
make[4]: *** [Makefile:703: nl.po-create] Error 1


What can be done?


nl.po is not missing in my tree. Is it possible that you unintentionally 
deleted it in your local tree?
Pavel


That was indeed the case. Weird that it happened right after a fresh 
clone on a new machine. Sorry for the mistake.

--
lorenzo

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

File nl.po does not exist

[Lorenzo Bertini]

Dear list,

I can't build master anymore. It says:


make[3]: «ja.gmo» is up to date.
make[3]: «nb.gmo» is up to date.
make[4]: entering directory «.../lyx/po»
File nl.po does not exist. If you are a translator, you can create it through 
'msginit'.
make[4]: *** [Makefile:703: nl.po-create] Error 1


What can be done?
--
lorenzo
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] Honor Update::SinglePar properly

[Lorenzo Bertini]

Il 21/02/23 17:01, Scott Kostyshak ha scritto:

On Wed, Feb 20, 2019 at 02:37:03PM +0100, Jean-Marc Lasgouttes wrote:
Found an instance that seems to be missing an update.

Reproducing requires some fast typing. It is only 30% reproducible even
after a shot of espresso, but 100% reproducible if I cheat with xdotool.

To reproduce:

1. Open the attached document.
2. Place the cursor inside the empty math inset.
3. Very quickly type "\upsil".

I get the attached screenshot.

If you are on Linux with X, you can use the following instead of typing
quickly:

# enter this into a terminal window after opening missing-update-screenshot.png.
sleep 5s &&
# Now switch to LyX and put the cursor in the math inset.
xdotool type --clearmodifiers --delay 0 "\upsil" &&
xdotool key Tab

Can anyone reproduce?

Scott


Since a couple years I found a very similar issue in master (that wasn't 
there in 2.3). Trying to complete with TAB any math command very fast 
produces that result.


Note that this can be reproduced consistently only on my laptop, which 
is quite old and slow; to reproduce on newer hardware you have to be 
really fast, or it doesn't happen.


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

Re: QRegExp is deprecated in qt6

[Lorenzo Bertini]

Il 12/02/23 20:53, Scott Kostyshak ha scritto:

On Sun, Feb 12, 2023 at 08:46:31PM +0100, Lorenzo Bertini wrote:

Dear list,

trying to compile with --enable-qt6 gives the following error:


qstring_helpers.cpp:21:10: fatal error: QRegExp: File o directory non esistente
21 | #include 
   |  ^


In the page https://doc.qt.io/qt-6/qregexp.html it says:


This class is deprecated in Qt 6. Please use QRegularExpression instead for all 
new code


What can be done to help?


Hi Lorenzo,

Which version or Git hash are you trying to compile?

Scott


Master branch

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

QRegExp is deprecated in qt6

[Lorenzo Bertini]

Dear list,

trying to compile with --enable-qt6 gives the following error:


qstring_helpers.cpp:21:10: fatal error: QRegExp: File o directory non esistente
   21 | #include 
  |  ^


In the page https://doc.qt.io/qt-6/qregexp.html it says:


This class is deprecated in Qt 6. Please use QRegularExpression instead for all 
new code


What can be done to help?

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

Re: Override mode for local layout / how to unset parameter

[Lorenzo Bertini]

On 03/01/23 18:50, Richard Kimberly Heck wrote:

On 1/3/23 11:49, Lorenzo Bertini wrote:

Hi,

I hope you all had wonderful holidays. I'm doing some tests with local 
layouts, and I was wondering what is the modality with which a local 
layout overrides the default: does it completely erase the latter and 
uses your edits, or does it override only the attributes you've modified?


The latter. Layouts are loaded successively: First, the document class 
layout; then the modules; then the local layout. Each one can either add 
to or over-write previous settings. This technique is used in many of 
the document class layouts themselves: They import 'standard' settings, 
then modify what needs modifying.



Also, suppose I want to "unset" a layout attribute that is set to 
something in the default layout, for example "DocbookWrapperTag" 
because I don't want wrapping: I can obtain what I want doing

> DocbookWrapperTag ""
but is there a better way?


That's the way to do it.

Riki




Many thanks!

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

Override mode for local layout / how to unset parameter

[Lorenzo Bertini]

Hi,

I hope you all had wonderful holidays. I'm doing some tests with local 
layouts, and I was wondering what is the modality with which a local 
layout overrides the default: does it completely erase the latter and 
uses your edits, or does it override only the attributes you've modified?


For example:

default  |   local  |   case 1   |   case 2   |
--|
Style Test   | Style Test   |||
  Attr1 foo  |   Attr1 woo  | Attr1 woo  | Attr1 woo  |
  Attr2 bar  |  || Attr2 bar  |
End  | End  |||

Also, suppose I want to "unset" a layout attribute that is set to 
something in the default layout, for example "DocbookWrapperTag" because 
I don't want wrapping: I can obtain what I want doing

> DocbookWrapperTag ""
but is there a better way?

Cheers

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

Re: Lyx is listed as proprietary software in gnome software

[Lorenzo Bertini]

Il 13/12/22 17:27, José Matos ha scritto:

On Mon, 2022-12-12 at 21:36 +0100, Lorenzo Bertini wrote:

Hi list,

just a heads up that for some reason LyX is listed as having a
proprietary license in gnome software. I don't know what is the
cause.
We might want to fix this soon. Any suggestions on who I can contact?

--
Lorenzo


What is the distribution that you are using?



Yes sorry, I was in a rush. I'm on Debian testing (11) with Gnome 43. 
Searching a bit I found that this is indeed a somewhat common packaging 
problem and I should contact the maintainer. Thanks anyway


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

Lyx is listed as proprietary software in gnome software

[Lorenzo Bertini]

Hi list,

just a heads up that for some reason LyX is listed as having a 
proprietary license in gnome software. I don't know what is the cause. 
We might want to fix this soon. Any suggestions on who I can contact?


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

Re: Local layout syntax highlight foundation

[Lorenzo Bertini]

Il 19/10/22 18:58, Pavel Sanda ha scritto:

On Fri, Oct 07, 2022 at 07:22:30PM +0200, Lorenzo Bertini wrote:

2. LyXHighlighter differs a lot from LaTeXHighlighter: doesn't rely on regex
as much. I was wondering if a merge could be possible, considering local
layout can include Latex bits.


If merging possible that's always good. If they differ too much one of them
is likely inferior in its design? :)


Eh, this time around is not easy to determine; Latex has to account to 
math and other stuff, and the general syntax is very different.





3. Generic regex based on position or keyword recognition. Which one?


What are the implications?


| regex | keywords |
|---|--|
| *X* harder to maintain| *V* easier to maintain   |
|---|--|
| *V* fewer lines, no database  | *X* needs extensive keyword db   |
|---|--|
| *X* relies on position only   | *V* only highlights  |
| highlights wrong keywords | working keywords |

But then again this was more of a proof of concept. Thanks for the insights.

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

Local layout syntax highlight foundation

[Lorenzo Bertini]

Hello list,

attached is a patch that adds a syntax highlighter to the local layout 
QTextEdit that supports some very basic LyX syntax. I remember someone 
asking for this, but nonetheless it can be useful.


I've encountered some problems and I would appreciate your help:

1. I can't find how to put files I've added to git inside a patch to 
send, so I have attached the two files, both go in src/frontend/qt. Sorry :)
2. LyXHighlighter differs a lot from LaTeXHighlighter: doesn't rely on 
regex as much. I was wondering if a merge could be possible, considering 
local layout can include Latex bits.

3. Generic regex based on position or keyword recognition. Which one?
4. Syntax keywords are hardcoded right now (I only added a few 
properties because it's tedious work and there's probably a better way). 
Is there a place where I can find all keywords LyX uses in a layout?


Thanks a lot in advance

Lorenzodiff --git a/src/frontends/qt/GuiDocument.cpp b/src/frontends/qt/GuiDocument.cpp
index b3f31302dd..938bdb30c1 100644
--- a/src/frontends/qt/GuiDocument.cpp
+++ b/src/frontends/qt/GuiDocument.cpp
@@ -21,6 +21,7 @@
 #include "GuiIndices.h"
 #include "GuiSelectionManager.h"
 #include "LaTeXHighlighter.h"
+#include "LyXHighlighter.h"
 #include "Validator.h"
 
 #include "LayoutFile.h"
@@ -605,6 +606,7 @@ void PreambleModule::editExternal() {
 LocalLayout::LocalLayout(QWidget * parent)
 	: UiWidget(parent), current_id_(nullptr), validated_(false)
 {
+	(void) new LyXHighlighter(locallayoutTE->document());
 	locallayoutTE->setFont(guiApp->typewriterSystemFont());
 	locallayoutTE->setWordWrapMode(QTextOption::NoWrap);
 	connect(locallayoutTE, SIGNAL(textChanged()), this, SLOT(textChanged()));
diff --git a/src/frontends/qt/Makefile.am b/src/frontends/qt/Makefile.am
index 9ca258d9d3..50e944c9c8 100644
--- a/src/frontends/qt/Makefile.am
+++ b/src/frontends/qt/Makefile.am
@@ -139,6 +139,7 @@ SOURCEFILES = \
 	LengthCombo.cpp \
 	LyXFileDialog.cpp \
 	LaTeXHighlighter.cpp \
+	LyXHighlighter.cpp \
 	LayoutBox.cpp \
 	Menus.cpp \
 	PanelStack.cpp \
@@ -164,6 +165,7 @@ NOMOCHEADER = \
 	GuiPainter.h \
 	GuiWorkArea_Private.h \
 	LaTeXHighlighter.h \
+	LyXHighlighter.h \
 	qt_i18n.h \
 	qt_helpers.h \
 	Toolbars.h
// -*- C++ -*-
/**
 * \file LyXHighlighter.h
 * This file is part of LyX, the document processor.
 * Licence details can be found in the file COPYING.
 *
 * \author Bo Peng
 *
 * Full author contact details are available in file CREDITS.
 */

#ifndef LYXHIGHLIGHTER_H
#define LYXHIGHLIGHTER_H

#include 
#include 
#include 

class QTextDocument;
class QString;

namespace lyx {
namespace frontend {

class LyXHighlighter : public QSyntaxHighlighter
{
public:
	explicit LyXHighlighter(QTextDocument * parent);

protected:
	void highlightBlock(QString const & text) override;

private:
	struct HighlightRule {
		QRegularExpression pattern;
		QTextCharFormat format;
	};
	QList highlightRules;
	
	void appendRuleFromPattern(QString const & pattern,
			   QTextCharFormat & format);
	void appendRulesFromPatternList(QStringList const & patterns,
	QTextCharFormat & format);
	
	QTextCharFormat blockFormat;
	QTextCharFormat propFormat;
	QTextCharFormat quoteFormat;
	QTextCharFormat commentFormat;
	QTextCharFormat statFormat;
	
};

} // namespace frontend
} // namespace lyx

#endif // LYXHIGHLIGHTER
/**
 * \file LyXHighlighter.cpp
 * This file is part of LyX, the document processor.
 * Licence details can be found in the file COPYING.
 *
 * \author Bo Peng
 *
 * Full author contact details are available in file CREDITS.
 */

#include 

#include "LyXHighlighter.h"
#include "qt_helpers.h"

#include 
#include 

namespace lyx {
namespace frontend {


void LyXHighlighter::appendRuleFromPattern(QString const & pattern,
		   QTextCharFormat & format) {
	HighlightRule rule;
	rule.pattern = QRegularExpression(pattern);
	rule.format = format;
	highlightRules.append(rule);
}

void LyXHighlighter::appendRulesFromPatternList(QStringList const & patterns,
QTextCharFormat & format) {
	for (const QString  : patterns) {
		appendRuleFromPattern(pattern, format);
	}
}


LyXHighlighter::LyXHighlighter(QTextDocument * parent)
	: QSyntaxHighlighter(parent)
{
	blockFormat.setForeground(Qt::blue);
	blockFormat.setFontWeight(QFont::Bold);
	
	propFormat.setForeground(Qt::red);
	propFormat.setFontWeight(QFont::Bold);
	
	statFormat.setForeground(Qt::magenta);
	statFormat.setFontWeight(QFont::Bold);
	
	quoteFormat.setForeground(Qt::green);
	
	QStringList blockPatterns;
blockPatterns << "\\bStyle\\b"			<< "\\bInsetLayout\\b" << "\\bEnd\\b"
  << "\\bArgument\\b"		<< "\\bEndArgument\\b"
  << "\\bFont\\b"			<< "\\bEndFont\\b"
  << "\\bLabelFont\\b"		<< "\\bEndLabelFont\\b"
  << "\\bHTMLStyle\\b"		<< "\\bEndHTMLStyle\\b"
  << "\\bAddToPreamble\\b"	<< "\\bAddToHTMLPreamble\\b" << "\\bEndPreamble\\b";
	
	QStringList propPatterns;
propPatterns << "\\bFormat\\b"		<< "\\bLyXType\\b"
 << "\\bLatexType\\b"	<< 

Re: Wiki problems and where to report them

[Lorenzo Bertini]

Il 01/09/22 15:01, Pavel Sanda ha scritto:

On Thu, Sep 01, 2022 at 01:48:30PM +0200, Lorenzo Bertini wrote:

I can start maybe updating some pages with what I know,


That would be nice indeed.


but there are some things I just can't do as user.


Feel free to bring whatever access issues you have, we'll try to be helpful.


Where do I report for example that this page
https://wiki.lyx.org/Devel/ReleaseNotes has not been updated in years and
needs to be merged with https://wiki.lyx.org/LyX/NewInLyX24?


There is no one to report to. Simply edit/fix/remove obsoleted stuff.
Or ask here if unsure about some changes.
In this particular case the ReleaseNotes is so off that you can just delete it
(or add correct links to newer versions).


Or that https://wiki.lyx.org/Devel/LyXGit and https://wiki.lyx.org/Devel/Git
are basically the same thing and can be merged?


Again if you known git enough that you know what you are doing feel free to
merge them and delete the obsolete one.


Oh, ok. I'll see.




Also, I found a cool cookbook recipe for PmWiki that allows blocks of code
with highlighting, which is something I really miss here:
https://www.pmwiki.org/wiki/Cookbook/SourceBlock.


Does this need some new module to be installed?

Pavel


It requires geshi (downloadable from https://github.com/GeSHi/geshi-1.0) 
and the sourceblock recipe (at 
https://www.pmwiki.org/pmwiki/uploads/Cookbook/sourceblock.php). I tried 
it on a dummy server with latest pmwiki and it works out of the box.


But then again, we would only need it on Devel pages, and not in all of 
them. Now that I think about it it's pretty overkill.

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

Re: Trac: Invalid username or password

[Lorenzo Bertini]

Il 01/09/22 16:01, Jean-Marc Lasgouttes ha scritto:

Le 29/08/2022 à 09:14, Jürgen Spitzmüller a écrit :

Has anyone found a solution?


We'll have to wait until somebody with access to the database (Riki,
JMarc) is back.


I reverted to the passwords from August 12, and everything seems OK now.

JMarc



I can log in now. Thanks
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Wiki problems and where to report them

[Lorenzo Bertini]

Hello,

the state of Lyx wiki seems not very healthy. Many pages are outdated 
(some haven't been updated in 12 years) and groups have grown too much 
so that they now contain maybe too many pages.


Many times I wanted to find something it takes a long time to navigate 
through the groups and categories, and when i found it it's usually very 
outdated and mentions tools not existing anymore. I can start maybe 
updating some pages with what I know, but there are some things I just 
can't do as user.


Where do I report for example that this page 
https://wiki.lyx.org/Devel/ReleaseNotes has not been updated in years 
and needs to be merged with https://wiki.lyx.org/LyX/NewInLyX24? Or that 
https://wiki.lyx.org/Devel/LyXGit and https://wiki.lyx.org/Devel/Git are 
basically the same thing and can be merged?


Also, I found a cool cookbook recipe for PmWiki that allows blocks of 
code with highlighting, which is something I really miss here: 
https://www.pmwiki.org/wiki/Cookbook/SourceBlock.


Big thanks,

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

Re: Add font to recognized fonts

[Lorenzo Bertini]

Il 30/08/22 08:58, Jürgen Spitzmüller ha scritto:

Am Montag, dem 29.08.2022 um 22:44 +0200 schrieb Lorenzo Bertini:

Hello,

I noticed there are some fonts available for Latex that do not appear
in
Lyx's document settings: an example is Caladea Font. This font comes
in
"texlive-font-extra" package in Debian, so it's something commonly
used.

Right now I use "\usepackage{caladea}" in an "AddToPreamble" custom
layout section. How would I add it to Lyx's menu of recognized fonts?
To
be clear: document settings -> fonts section -> roman dropdown menu.

Things I've found so far: GuiDocument uses FontModule class to fill
up the menu. Where would I go from here?


lib/latexfonts. The file has some documentation.

If you copy this file to your local lyx folder, you don't need to
recompile.



Thanks in advance

Lorenzo


HTH,


Easier than I thought, thanks! However, in the menu it says "not 
installed", and font is not applied (using \usepackage{caladea} works 
and font is installed properly). I just added



+Font caladea
+   GuiName  "Caladea"
+   Family   rm
+   Package  caladea
+EndFont


How can I fix this? I tried reconfiguring / recompiling to no avail.

In the file it says that a change in that is a format change. Will this 
have to wait for Lyx 2.5?diff --git a/lib/latexfonts b/lib/latexfonts
index 3120233fd8..2759059eac 100644
--- a/lib/latexfonts
+++ b/lib/latexfonts
@@ -118,6 +118,12 @@ Font bookman
 	Package  bookman
 EndFont
 
+Font caladea
+	GuiName  "Caladea"
+	Family   rm
+	Package  caladea
+EndFont
+
 Font ccfonts
 	GuiName  "Concrete Roman"
 	Family   rm
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Add font to recognized fonts

[Lorenzo Bertini]

Hello,

I noticed there are some fonts available for Latex that do not appear in 
Lyx's document settings: an example is Caladea Font. This font comes in 
"texlive-font-extra" package in Debian, so it's something commonly used.


Right now I use "\usepackage{caladea}" in an "AddToPreamble" custom 
layout section. How would I add it to Lyx's menu of recognized fonts? To 
be clear: document settings -> fonts section -> roman dropdown menu.


Things I've found so far: GuiDocument uses FontModule class to fill up 
the menu. Where would I go from here?


Thanks in advance

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

Re: Trac: Invalid username or password

[Lorenzo Bertini]

Bump!

I'm getting the same message :(. Has anyone found a solution?

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

Re: Quick newbie question

[Lorenzo Bertini]

Il 02/05/22 13:39, Pavel Sanda ha scritto:

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


Thank you so much, I was able to solve most of the issues running autogen.sh

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

Re: Quick newbie question

[Lorenzo Bertini]

Il 01/01/22 19:01, Lorenzo Bertini ha scritto:

Il 01/01/22 17:54, Lorenzo Bertini ha scritto:

Dear list,

I found a bug and needed to bisect, so i moved back HEAD to an old 
commit, then configured and built. I went back to master and can't 
build anymore because its missing `nod.hpp` file; no git command seems 
to restore this file (git reset --hard, creating a new master branch 
tracking origin/master, etc).


I would like not to clone again as its very slow, but all I find on 
the internet are commands I already tried. What should i do?


Thank you in advance,

Lorenzo (lynx)


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

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


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.


Thanks,

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

Re: LyXHTML doc doesn't pass validation

[Lorenzo Bertini]

Il 23/03/22 19:03, Thibaut Cuvelier ha scritto:
On Wed, 23 Mar 2022 at 18:43, Lorenzo Bertini 
mailto:lorenzobertin...@gmail.com>> wrote:


Running a very simple LyXHTML doc (a section with a few paragraphs)
against this validator https://validator.w3.org/check
<https://validator.w3.org/check> reports some
errors, I don't really know if we care or not:

1. value of attribute "dir" cannot be "auto"; must be one of "ltr",
"rtl"
2. element "section" undefined

Is this a problem? I just wanted to check if I could use the 
tag but its not part of the specification.


What version of HTML are you checking against? There are some glimpses 
of HTML5 in the current output. For instance, dir="auto" and section are 
perfectly legal in HTML5 
(https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/dir 
<https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/dir> and 
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/section 
<https://developer.mozilla.org/en-US/docs/Web/HTML/Element/section>)


I checked XHTML 1.0, as it should be what LyX outputs. I was about to 
check up some of the xhtml_output code to maybe add `figure` 
environments, but since its XHTML there's very little allowed.

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

LyXHTML doc doesn't pass validation

[Lorenzo Bertini]

Running a very simple LyXHTML doc (a section with a few paragraphs) 
against this validator https://validator.w3.org/check reports some 
errors, I don't really know if we care or not:


1. value of attribute "dir" cannot be "auto"; must be one of "ltr", "rtl"
2. element "section" undefined

Is this a problem? I just wanted to check if I could use the  
tag but its not part of the specification.


Best regards,

Lorenzo (lynx)
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Lots of duplicate code in docbook

[Lorenzo Bertini]

Il 21/03/22 11:49, Daniel ha scritto:

On 2022-03-21 10:55, Lorenzo Bertini wrote:
There is some degree of duplication between Docbook and LyXHTML code. 
I think its because the latter is much older and Thibaut had to write 
its own to produce Docbook. This has been brought up also when 
addressing MathML production. I agree LyX needs more standard XML 
generating functions.


Its part of a larger theme about XML production, and there was a talk 
sometime ago about using a library for this.


I might be misunderstanding your comment. But actually, I wanted to 
point not to the way XML is generated but more to the actual content, 
for example, the specific attributes of an element which seem to be 
duplicated. But maybe that problem is somehow dependent on the general 
generation of XML?


Daniel


Sorry, I meant that code duplication is probably due to the different 
maintainers for the two formats and the fact that one is much older and 
has been untouched for a long (LyXHTML). I remember Thibaut saying he 
branched from LyXHTML knowingly, even if it would have meant rewriting 
some stuff. Looking at your examples, this might be the case.


I think a common interface to write XML elements like tables, tags, etc, 
would help reduce this, but it will be a lot of effort. I'll wait for 
Thibaut and Richard to chime in on this.


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

Re: Lots of duplicate code in docbook

[Lorenzo Bertini]

Il 21/03/22 10:37, Daniel ha scritto:
I have no knowledge about docbook. I never used it. I was just wondering 
why so code is duplicated in the docbook functions. For example, 
Tabular::docbookRowAsHTML and Tabular::docbookRowAsCALS seems to 
duplicate much of Tabular::xhtmlRow. Isn't that an issue when adding new 
features? Why not have common functions with only parts that differ or so?


Daniel


There is some degree of duplication between Docbook and LyXHTML code. I 
think its because the latter is much older and Thibaut had to write its 
own to produce Docbook. This has been brought up also when addressing 
MathML production. I agree LyX needs more standard XML generating functions.


Its part of a larger theme about XML production, and there was a talk 
sometime ago about using a library for this.

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

Re: Missing tabular-feature_set-all-lines.svgz

[Lorenzo Bertini]

Il 18/03/22 10:20, Jürgen Spitzmüller ha scritto:

Am Freitag, dem 18.03.2022 um 09:18 +0100 schrieb Lorenzo Bertini:

Hello,

since a week ago I can't build LyX anymore, as it complains that the
file "tabular-feature_set-all-lines.svgz" is necessary for "all-am",
but
there are no rules to make it, as it is an image. I checked and it's
not
present in origin repo. What can I do to start building again?


The necessary changes in makefile.am have been done AFAICS.

Did you try make distclean & ./autogen.sh

HTH,
Jürgen


Thanks, this worked.

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

Missing tabular-feature_set-all-lines.svgz

[Lorenzo Bertini]

Hello,

since a week ago I can't build LyX anymore, as it complains that the 
file "tabular-feature_set-all-lines.svgz" is necessary for "all-am", but 
there are no rules to make it, as it is an image. I checked and it's not 
present in origin repo. What can I do to start building again?


Thanks in advance,

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

Re: Quick newbie question

[Lorenzo Bertini]

Il 01/01/22 17:54, Lorenzo Bertini ha scritto:

Dear list,

I found a bug and needed to bisect, so i moved back HEAD to an old 
commit, then configured and built. I went back to master and can't build 
anymore because its missing `nod.hpp` file; no git command seems to 
restore this file (git reset --hard, creating a new master branch 
tracking origin/master, etc).


I would like not to clone again as its very slow, but all I find on the 
internet are commands I already tried. What should i do?


Thank you in advance,

Lorenzo (lynx)


Update: file was never gone, just in its folder "3rdparty". Compilation 
now works after countless attemps, and I didn't really change anything :).

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

Quick newbie question

[Lorenzo Bertini]

Dear list,

I found a bug and needed to bisect, so i moved back HEAD to an old 
commit, then configured and built. I went back to master and can't build 
anymore because its missing `nod.hpp` file; no git command seems to 
restore this file (git reset --hard, creating a new master branch 
tracking origin/master, etc).


I would like not to clone again as its very slow, but all I find on the 
internet are commands I already tried. What should i do?


Thank you in advance,

Lorenzo (lynx)
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Quick questions

[Lorenzo Bertini]

Hello list, just a couple of quick questions.
I wanted to get a meaningful output out of valgrind so i needed to build 
a debug version:


1. how do i tell autotools that i want this? I tried some LyX pages but 
they don't specifically say how. Is it the default behavior? In case, 
how do i get release output?


Also, on my computer i have debian 11 and LyX 2.3.6 as package. I have 
LyX 2.4 cloned from git on a folder:


2. how do i download the debug symbols for 2.4? The package lyx-dbgsym 
is for 2.3.6.
3. LyX 2.4 has overwritten something in the .lyx folder so LyX 2.3.6 
doesn't work anymore; how do i keep them separated?


Thank you kindly in advance,

Lorenzo (lynx on trac)
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Edit Externally: implement for math insets?

[Lorenzo Bertini]

Il 12/05/21 16:32, Scott Kostyshak ha scritto:

I'm surprised that this question about toggling between LyX math and
LaTeX has received a lot of views:

   
https://tex.stackexchange.com/questions/45301/in-lyx-is-there-a-way-to-toggle-the-display-of-tex-code-in-math-expressions/46328#46328

I don't know anything about how LyX stores math in memory, but in the
file format if I remember correctly we essentially store LaTeX. Does
this mean we could allow "Edit externally" for math insets?

Scott


Up to my limited understanding of this, Lyx internally stores math in 
nested insets and the converts it on the fly for outputting or just 
copy-pasting the expression. The cool feature is that each inset class 
specifies how it should be output in each format: having the possibility 
to switch to raw LaTeX would do two things im not sure are good
1. it would hide this important mechanic and make the user think it's 
all LaTeX;

2. it would require conversion back and forth when writing expressions.

Also, you can type any expression you want on an exteral editor and just 
paste it in lyx or viceversa. I think if we want to add this we must 
make clear that latex is just another method of writing.

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

Re: Documentation Help

[Lorenzo Bertini]

Il 13/01/21 18:22, Richard Kimberly Heck ha scritto:
> Hi, everyone,
> 
> We hope to release LyX 2.4.0 in the next couple months. Before then,
> there is some work that needs to be done on the documentation. If you've
> always wanted to contribute to LyX but haven't because you don't know
> how to code, then this is your chance!
> 
> The main task that needs doing is to copy the changes made in the
> English documentation over into the Spanish, French, German, and
> Japanese manuals, so that the translators can do translate it. You do
> NOT have to speak one of these languages to do this (though that might
> be helpful). It really is just a matter of going through the English
> manual, finding the new or changed material (which is marked with
> change-tracking), and pasting it into the other manuals. It's rote work,
> but important work nonetheless.
> 
> Longer-term, we could also use someone to act as documentation manager
> during the 2.5 development cycle and to do this kind of work along the
> way. If you'd be interested in that job, please do let us know.
> 
> Riki

I can do Spanish! I found how to look at changes, but then do I just
copy them in a local version of the translated manual?

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

Re: XML stream writer library

[Lorenzo Bertini]

Il 08/01/21 03:00, Thibaut Cuvelier ha scritto:

A tour of some C++ libraries for XML:
- RapidXML: mostly unmaintained since 2013, no support for namespaces 
(except in forks: https://github.com/dwd/rapidxml 
)
- Boost Property Tree: no XML parser, which limits further use (it can 
use RapidXML though, see above)

- libstudxml: C++ library, designed for speed, no DOM
- libxml2: C library, designed for features and not speed (also includes 
XPath and XSLT, DTD and XML Schema, namespaces), "mature" and barely not 
evolving anymore

- libxml++: depends on glibmm2
- Xerces-C++: C++ library, designed for features and not speed (also 
includes XPath, DTD and XML Schema, namespaces), "mature" and barely not 
evolving anymore; no XSLT (Xalan could be used, but it only works with a 
ancient version of Xerces; XQuilla implemented XPath 2, but is no more 
developed since 2016)
- Expat: C library, designed for speed, no DOM by default (provided by 
https://github.com/kolotsey/expat-dom 
), with namespaces
- tinyxml2: C++ library, designed for speed only (also includes XPath 
through the unmaintained https://github.com/stanthomas/tinyxml2-ex 
, no validation, no 
namespaces), mature and slowly evolving
- pugixml: C++ library, designed for speed with a few features (like 
XPath, no validation, no namespaces), mature and evolving
- libroxml: C library, no clear design goal (includes XPath, namespaces, 
no validation), evolving
- Saxon-C: C/C++ wrapper of the state-of-the-art Java library, largest 
amount of features (XPath and XSLT 3, DTD and XML Schema validation -- 
extension for RelaxNG: http://www.cfoster.net/saxon-jing/ 
 --, namespaces), very mature, 
really evolving (both performance and features), but it requires a JVM 
(Excelsior is built-in, even though it's not been maintained for quite a 
long time)
- Qt: no, I was joking :). Qt XML is not supported anymore, it's 
recommended to switch to QXmlStreamReader and QXmlStreamWriter (which 
are only SAX-like). Qt XML Patterns used to have XPath, XSLT, and XML 
Schema, but it's been deprecated a while ago (Qt 5.13 for the last 
wake-up call, but it hasn't been touched since Qt 4, basically)


If LyX is being really serious about XML (i.e. moving as many things as 
possible to XML technologies), Saxon is probably the way to go. 
Otherwise, it's going to be too heavy to ship Saxon and a JVM along with 
LyX. Instead, pugixml seems to me like a good choice: a few features 
(XPath is the most relevant for LyX, and included in the base library, 
no need for addons), good performance, still maintained (there is a 
chance to have bugs fixed in a newer version, plus security 
vulnerabilities taken care of).
Was this addressed in the virtual meeting? Also, since Xerces-C was the 
most feature full and mature after Saxon-C, I was curious as to why you 
didn't mention it.


Anyhow, I think that for a start we'd need only the most basic features 
(tag insertion, indent), as was the purpose of #12055 in the first place 
(I'm sorry to have opened this pandora's box), so maybe no harm will 
come if we start wrapping pugi.


Let me know what you think, and if this is not the time for this, as 
with LyX 2.4 coming out there might be other things that need focus.

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

Re: XML stream writer library

[Lorenzo Bertini]

I think almost all the options are on the table at this point. For the 
sake of completeness I think it's worth mentioning DOM library Boost 
Property Tree, which popped up frequently while searching.


I think Thibaut is right when saying that, for the way LyX is structured 
now, a SAX writer would be more appropriate, because we won't work on 
xml directly, but convert the LyX file. However most of the libraries 
have a DOM approach, and also, if someday we'll convert LyX format to 
something xml-like, we might have to start all of this again.


I did a small benchmark with pugixml and to both read and write a xml 
document of 2.2Mb of equivalent ~100/120 pages chock full of math: it 
takes negligble time to both read and write on my really modest laptop 
A10-9600). Peak memory consumption was 14Mb, but since some MathML was 
corrupted (it has trouble with backslash \) it's possible it might be 
way less once fixed: LyX consumption opening the corresponding LyX file 
was ~120Mb. The benchmark table in 
 
seems to indicate that pugixml and RapidXML have performance just one 
order greater than strlen, so I don't think parse time will ever be a 
problem.


I'm unfamiliar with the concept of "wrapping" libraries and "layers": is 
it when you write your own classes and methods on top of some common 
stuff those libraries do, so if for whatever reason you have to switch 
you can "plug" another easily?


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

XML stream writer library

[Lorenzo Bertini]

Hello list,

In 12055 , discussing the merge
of some MathMLStream and XmlStream components, we were contemplating the
possibility of using an external library to handle XML streams, for
example with indentation and tag insertion. One of the candidates was
QXmlStreamWriter  class,
but with the talk about removing unnecessary Qt components we thought to
ask the list.

Lest us know what do you think it's the best course, and if you know of
other libraries we should look.

Lo (lynx in trac).

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

Contributions licensing

[Lorenzo Bertini]

Hello list, I (lynx in bug tracker) am here licensing all my (hopefully) future 
contributions and the small patch for #12050 to LyX under GNU GPL v2 or any 
later version.

Since I'm here I'd really like to ask which file and functions to look to 
understand how LyX handles \left \right: so far i managed to get (from 
InsetMathDelim) that the delimiters get stored into left_ right_ docstrings. 
I'd like to make it so InsetMathDelim::mathmlize recognizes if it's ( or 
\left(. Any help is greatly appreciated.

Thank you, Lo.

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

Re: Preamble section patch

[Lorenzo Bertini]

Il 28/09/20 22:57, Richard Kimberly Heck ha scritto:
> So can you create a file with the new preamble that might cause a problem so 
> we can see exactly what it is?
> 
> Riki

My problem is with the following (pseudo)code, that is present in
writeLatex, but not in my code:

> // Check if the user preamble contains uncodable glyphs
> odocstringstream user_preamble;
> Encoding * enc = features.runparams().encoding;
> if (enc) {
>   for (n in preamble.size()) {
>   char c = preamble[n];
>   if (!enc->encodable(c)) LYXERR0("Uncodable character");
>   elseuser_preamble.put(c);
>   }
> }

I tried manually inserting copy-pasted "illegal" utf-8 characters
(example: ࠀ) into both preambles (if this sounds stupid it's because it
is, I don't know much about encoding) and neither produced the expected
error (the LaTeX one produced an encoding error by other means, the
message wasn't the one expected).

While doing this I found that saving the preamble and closing the window
(triggering saving the cursors position, etc) and opening it again
breaks the second preamble tab text: don't bother looking into the
patch, it needs a lot of fixing. I'm on it.

Sorry for being rushed, Lo
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Preamble section patch

[Lorenzo Bertini]

Can you give more details on what you mean by "far from perfect"?
Yes, sorry! The thing I'm not happy with is that patch makes it so the 
HTML preamble gets stored in a new bufferParams docstring, but it 
doesn't get checked for illegal characters and it's "brutally" printed 
in writeHTMLSource in buffer.cpp, while the LaTeX preamble string 
undergoes more processing in writeLaTeX in BufferParams.cpp and 
writeLaTeXSource in Buffer.cpp.


I wish I could dig deeper on LaTeX and LyXHTML outputting, but I feel 
like this is too hard of a start. Ill pick something easier next time.


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

Preamble section patch

[Lorenzo Bertini]

Hello list,
sorry for the long delay, I have attached the patch I made to have a
general preamble section. It's short and far from perfect but works. I
followed the git guide on lyx.org scrupulously (i'm new to vcs), but
let me know if something's amiss.

Best regards, Lo
From f38be31816ad8f519f29bbc74c8cf1e6663faca0 Mon Sep 17 00:00:00 2001
From: Lorenzo Bertini 
Date: Tue, 22 Sep 2020 20:14:48 +0200
Subject: [PATCH] Preamble section generalization

---
 src/Buffer.cpp|  7 
 src/BufferParams.cpp  | 19 +++
 src/BufferParams.h|  4 +++
 src/frontends/qt/GuiDocument.cpp  | 37 +
 src/frontends/qt/GuiDocument.h|  3 +-
 src/frontends/qt/ui/PreambleUi.ui | 54 +++
 6 files changed, 104 insertions(+), 20 deletions(-)

diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index 2ef5768771..3090224d2e 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -2288,6 +2288,13 @@ Buffer::ExportStatus Buffer::writeLyXHTMLSource(odocstream & os,
 	 << "\n\n";
 			}
 		}
+		
+		// the user-defined preamble
+		if (!params().htmlpreamble.empty()) {
+			os << "\n"
+			   << params().htmlpreamble << "\n";
+		}
+		
 		os << "\n";
 	}
 
diff --git a/src/BufferParams.cpp b/src/BufferParams.cpp
index b5ae2d4cad..22b89fec4c 100644
--- a/src/BufferParams.cpp
+++ b/src/BufferParams.cpp
@@ -774,6 +774,8 @@ string BufferParams::readToken(Lexer & lex, string const & token,
 		}
 	} else if (token == "\\begin_preamble") {
 		readPreamble(lex);
+	} else if (token == "\\begin_htmlpreamble") {
+		readHtmlPreamble(lex);
 	} else if (token == "\\begin_local_layout") {
 		readLocalLayout(lex, false);
 	} else if (token == "\\begin_forced_local_layout") {
@@ -1211,6 +1213,15 @@ void BufferParams::writeFile(ostream & os, Buffer const * buf) const
 		   << to_utf8(tmppreamble)
 		   << "\n\\end_preamble\n";
 	}
+	
+	// the html preamble
+	if (!htmlpreamble.empty()) {
+		// remove '\n' from the end of preamble
+		docstring const tmphtmlpreamble = rtrim(htmlpreamble, "\n");
+		os << "\\begin_htmlpreamble\n"
+		   << to_utf8(tmphtmlpreamble)
+		   << "\n\\end_htmlpreamble\n";
+	}
 
 	// the options
 	if (!options.empty()) {
@@ -2820,6 +2831,14 @@ void BufferParams::readPreamble(Lexer & lex)
 	preamble = lex.getLongString(from_ascii("\\end_preamble"));
 }
 
+void BufferParams::readHtmlPreamble(Lexer & lex)
+{
+	if (lex.getString() != "\\begin_htmlpreamble")
+		lyxerr << "Error (BufferParams::readPreamble):"
+			"consistency check failed." << endl;
+
+	htmlpreamble = lex.getLongString(from_ascii("\\end_htmlpreamble"));
+}
 
 void BufferParams::readLocalLayout(Lexer & lex, bool forced)
 {
diff --git a/src/BufferParams.h b/src/BufferParams.h
index b42d622fb3..ea590653e7 100644
--- a/src/BufferParams.h
+++ b/src/BufferParams.h
@@ -357,6 +357,8 @@ public:
 	///
 	docstring preamble;
 	///
+	docstring htmlpreamble;
+	///
 	std::string options;
 	/// use the class options defined in the layout?
 	bool use_default_options;
@@ -596,6 +598,8 @@ private:
 	///
 	void readPreamble(Lexer &);
 	///
+	void readHtmlPreamble(Lexer &);
+	///
 	void readLocalLayout(Lexer &, bool);
 	///
 	void readLanguage(Lexer &);
diff --git a/src/frontends/qt/GuiDocument.cpp b/src/frontends/qt/GuiDocument.cpp
index 9b4b97dc76..2c30f6ac48 100644
--- a/src/frontends/qt/GuiDocument.cpp
+++ b/src/frontends/qt/GuiDocument.cpp
@@ -484,8 +484,11 @@ PreambleModule::PreambleModule(QWidget * parent)
 	(void) new LaTeXHighlighter(preambleTE->document(), true);
 	preambleTE->setFont(guiApp->typewriterSystemFont());
 	preambleTE->setWordWrapMode(QTextOption::NoWrap);
+	htmlPreambleTE->setFont(guiApp->typewriterSystemFont());
+	htmlPreambleTE->setWordWrapMode(QTextOption::NoWrap);
 	setFocusProxy(preambleTE);
 	connect(preambleTE, SIGNAL(textChanged()), this, SIGNAL(changed()));
+	connect(htmlPreambleTE, SIGNAL(textChanged()), this, SIGNAL(changed()));
 	connect(findLE, SIGNAL(textEdited(const QString &)), this, SLOT(checkFindButton()));
 	connect(findButtonPB, SIGNAL(clicked()), this, SLOT(findText()));
 	connect(editPB, SIGNAL(clicked()), this, SLOT(editExternal()));
@@ -498,8 +501,10 @@ PreambleModule::PreambleModule(QWidget * parent)
 	// horizontalAdvance() is available starting in 5.11.0
 	// setTabStopDistance() is available starting in 5.10.0
 	preambleTE->setTabStopDistance(tabStop * metrics.horizontalAdvance(' '));
+	htmlPreambleTE->setTabStopDistance(tabStop * metrics.horizontalAdvance(' '));
 #else
 	preambleTE->setTabStopWidth(tabStop * metrics.width(' '));
+	htmlPreambleTE->setTabStopWidth(tabStop * metrics.width(' '));
 #endif
 }
 
@@ -512,13 +517,14 @@ voi

Re: [Request/idea] Preamble generalization

[Lorenzo Bertini]

I managed to get the thing to work through your guidance and shameless
copy-paste: let me know if you find any problems. I generalized the
findText method decently, but the rest of the patch is still
hardcoded. Also, I don't fully understand why > is in
 but write  is in , and how the
whole outputting is done. Is there any documentation?

Lo
From 9914af1583355687e93662ac1019880799228e17 Mon Sep 17 00:00:00 2001
From: Lorenzo Bertini 
Date: Mon, 21 Sep 2020 20:08:32 +0200
Subject: [PATCH] Preamble section generalization

---
 src/Buffer.cpp|  7 
 src/BufferParams.cpp  | 19 +++
 src/BufferParams.h|  4 +++
 src/frontends/qt/GuiDocument.cpp  | 37 +
 src/frontends/qt/GuiDocument.h|  3 +-
 src/frontends/qt/ui/PreambleUi.ui | 54 +++
 6 files changed, 104 insertions(+), 20 deletions(-)

diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index 2ef5768771..3090224d2e 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -2288,6 +2288,13 @@ Buffer::ExportStatus Buffer::writeLyXHTMLSource(odocstream & os,
 	 << "\n\n";
 			}
 		}
+		
+		// the user-defined preamble
+		if (!params().htmlpreamble.empty()) {
+			os << "\n"
+			   << params().htmlpreamble << "\n";
+		}
+		
 		os << "\n";
 	}
 
diff --git a/src/BufferParams.cpp b/src/BufferParams.cpp
index b5ae2d4cad..22b89fec4c 100644
--- a/src/BufferParams.cpp
+++ b/src/BufferParams.cpp
@@ -774,6 +774,8 @@ string BufferParams::readToken(Lexer & lex, string const & token,
 		}
 	} else if (token == "\\begin_preamble") {
 		readPreamble(lex);
+	} else if (token == "\\begin_htmlpreamble") {
+		readHtmlPreamble(lex);
 	} else if (token == "\\begin_local_layout") {
 		readLocalLayout(lex, false);
 	} else if (token == "\\begin_forced_local_layout") {
@@ -1211,6 +1213,15 @@ void BufferParams::writeFile(ostream & os, Buffer const * buf) const
 		   << to_utf8(tmppreamble)
 		   << "\n\\end_preamble\n";
 	}
+	
+	// the html preamble
+	if (!htmlpreamble.empty()) {
+		// remove '\n' from the end of preamble
+		docstring const tmphtmlpreamble = rtrim(htmlpreamble, "\n");
+		os << "\\begin_htmlpreamble\n"
+		   << to_utf8(tmphtmlpreamble)
+		   << "\n\\end_htmlpreamble\n";
+	}
 
 	// the options
 	if (!options.empty()) {
@@ -2820,6 +2831,14 @@ void BufferParams::readPreamble(Lexer & lex)
 	preamble = lex.getLongString(from_ascii("\\end_preamble"));
 }
 
+void BufferParams::readHtmlPreamble(Lexer & lex)
+{
+	if (lex.getString() != "\\begin_htmlpreamble")
+		lyxerr << "Error (BufferParams::readPreamble):"
+			"consistency check failed." << endl;
+
+	htmlpreamble = lex.getLongString(from_ascii("\\end_htmlpreamble"));
+}
 
 void BufferParams::readLocalLayout(Lexer & lex, bool forced)
 {
diff --git a/src/BufferParams.h b/src/BufferParams.h
index b42d622fb3..ea590653e7 100644
--- a/src/BufferParams.h
+++ b/src/BufferParams.h
@@ -357,6 +357,8 @@ public:
 	///
 	docstring preamble;
 	///
+	docstring htmlpreamble;
+	///
 	std::string options;
 	/// use the class options defined in the layout?
 	bool use_default_options;
@@ -596,6 +598,8 @@ private:
 	///
 	void readPreamble(Lexer &);
 	///
+	void readHtmlPreamble(Lexer &);
+	///
 	void readLocalLayout(Lexer &, bool);
 	///
 	void readLanguage(Lexer &);
diff --git a/src/frontends/qt/GuiDocument.cpp b/src/frontends/qt/GuiDocument.cpp
index 9b4b97dc76..ffb639e19d 100644
--- a/src/frontends/qt/GuiDocument.cpp
+++ b/src/frontends/qt/GuiDocument.cpp
@@ -484,8 +484,11 @@ PreambleModule::PreambleModule(QWidget * parent)
 	(void) new LaTeXHighlighter(preambleTE->document(), true);
 	preambleTE->setFont(guiApp->typewriterSystemFont());
 	preambleTE->setWordWrapMode(QTextOption::NoWrap);
+	htmlPreambleTE->setFont(guiApp->typewriterSystemFont());
+	htmlPreambleTE->setWordWrapMode(QTextOption::NoWrap);
 	setFocusProxy(preambleTE);
 	connect(preambleTE, SIGNAL(textChanged()), this, SIGNAL(changed()));
+	connect(htmlPreambleTE, SIGNAL(textChanged()), this, SIGNAL(changed()));
 	connect(findLE, SIGNAL(textEdited(const QString &)), this, SLOT(checkFindButton()));
 	connect(findButtonPB, SIGNAL(clicked()), this, SLOT(findText()));
 	connect(editPB, SIGNAL(clicked()), this, SLOT(editExternal()));
@@ -498,8 +501,10 @@ PreambleModule::PreambleModule(QWidget * parent)
 	// horizontalAdvance() is available starting in 5.11.0
 	// setTabStopDistance() is available starting in 5.10.0
 	preambleTE->setTabStopDistance(tabStop * metrics.horizontalAdvance(' '));
+	htmlPreambleTE->setTabStopDistance(tabStop * metrics.horizontalAdvance(' '));
 #else
 	preambleTE->setTabStopWidth(tabStop * metrics.width(' '));
+	htmlPreambleTE->set

Re: [Request/idea] Preamble generalization

[Lorenzo Bertini]

Sorry for the old bump, but I managed to make a tabbed menu with
"LaTeX" and "HTML" as tabs for the "Preamble" section:

What I managed to do:
1) Buffer params received a new variable  that can be
written to and read from a LyX file just as old ;
2) "Preamble" section now has two tabs, each with a text box that
saves what's inside into  and 
respectively when the  function is called;
3) "find text" box and button work for the current selected tab;

What I couldn't do:
1) find out how to write  when outputting HTML;
I've been looking into "output_xhtml" and "output_latex" without luck;
where should I look?
2) check if  contains illegal characters (this should be
a simple copy-paste from the latex one, I'll look into it later);
3) make it so when the text box for the HTML tab is modified the
 button activates, just like the LaTeX tab does; where should I
look to learn how to notify that "settings have changed" when the tab
receives text?
4) avoid hardcoding some things: for example to make the "find" work
in the current tab I have explicitly used tab names; how does one make
this name or tab independent, in the perspective of adding more
preamble options? Should one?

Thank you in advance, I'm moving my first steps in this codebase and I
need a little starting kick. I started here because I thought I would
have been easier that attempting easyfixes, let me know if I'm wrong.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [Request/idea] Preamble generalization

[Lorenzo Bertini]

> UI-wise, this would probably be better than what we have, but you can
> already do this with Local Layout. Like this:
>
> Format 61
>
> AddToHTMLPreamble
>
> 
> h2.section { font-size: 150%; font-weight: bold; }
> 
>
> EndPremable
>
> You can put anything else in there that you want in the head block, too.
>
> Do feel free to file an enhancement request on the bug tracker.
>
> Riki

Thank you, this solves some problems for me. However now I'm
questioning whether the  section in document->settings
isn't just a shortcut for  in ? In this case I think putting them at the same level is
confusing, and prevented me from ever needing to look deeper in ; I understand not all users would want to learn this but it's
three lines to get a LaTeX or HTML preamble. Ideally there would be a
way to keep the generality of the  section that however
makes it super easy and intuitive to change a preamble.
I leave this decision to you and I'll not file a bug (feature) report
for now, but here's my two cents for keeping things clear and
functional:
1)  section gets removed
2)  section gets an "advanced" tab with the text entry
we have now, and an "easy" tab made by text boxes, buttons and toggles
(for a start, just containing the infamous LaTeX Preamble and HTML
Preamble, then maybe more).
Except for the advantages in clarity on preambles, I think this would
make way easier not only to tinker with layouts but also to learn how
Lyx works and what are the commands. I know this is a bit of an
overhaul, I'm just leaving this here as an idea.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

[Request/idea] Preamble generalization

[Lorenzo Bertini]

Hello devs,
the recent discussion about Lyx being not LaTeX centric and my need to
manually edit the CSS in LyXHTML output has got me thinking that the
 section in the document->settings could be
generalized to just  and contain the LaTeX preamble, CSS
etc. The main advantages would be:
1) less "special treatment" given to LaTeX;
2) more customizability for HTML and XHTML output, which is a
substantial perk of this output that is otherwise lost;
I'm thinking of something like this:
LaTeX preamble:
|-|
| \allordisplaybreaks |
|-|
CSS:
|-|
| h2.section {...|
|-|
Let me know what you think. Thanks a lot for this awesome program btw.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Possibly unwanted "stretchy" behavior in MathML output

[Lorenzo Bertini]

Hi,

my xhtml output trough the LyXHTML option had brackets that always
matched the height of the equation for paired \left( \right) brackets,
as one would expect, but also for plain ( ) ones, which is unexpected.
This of course led to the final output having some ridiculously sized
brackets. The problem is the MathML attribute "stretchy=true" added to
the output in both cases. I can't think of any reason why this would
be the intended behavior, especially since using \big( \big) yields
the requested bracket size.

I git-cloned the source (2.3.4), removed all the "stretchy=true" from
output-xhtml.cpp and built, and in the output there weren't any
height-matching brackets, but I don't know c++ too well and don't have
experience with this project code to make this happen only for \left(
\right) pairs. Can someone help me out?

I think it's system/machine independent but I tried it on Debian 10
Stable and Lyx 2.3.2 (Deb packaged); cloned 2.3.4.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel