Re: Editing equations as latex rather than graphically.

[Jean-Marc Lasgouttes]

Le 2 févr. 10 à 02:38, Tommaso Cucinotta a écrit :
This may be useful, for example, in case of mixed latex/lyx fans  
working at a paper, or for importing maths written previously in  
LaTeX keeping the original formatting/comments in a separate file.


I heard Vincent has an upcoming InsetPreview feature which I don't  
exactly know how would relate to this, perhaps both things may be  
worth to exist.


As far as I understand, the main point is to have the preview, right?  
Since this does not use the file conversion
stuff from insetexternal, I'd prefer indeed to have InsetPreview (or  
preview of ert) for these kind of uses.


I am not sure we want to advertise many ways of basically doing the  
same thing.


JMarc

RE: Editing equations as latex rather than graphically.

[Vincent van Ravesteijn - TNW]

I heard Vincent has an upcoming InsetPreview feature which I don't
exactly
know how would relate to this, perhaps both things may be worth to
exist.


Well, everything inside this Inset will get previewed. So if you put
your equation into an ert into this inset it will generate a preview of
the equation. This would only be necessary in cases which the math
editor does not handle. A common problem is math insets that need a
parameter e.g., xymatrix.

Vincent

Re: Goals for alpha 1

[Guenter Milde]

On 2010-02-01, José Matos wrote:
 On Friday 29 January 2010 22:38:05 Peter Kümmel wrote:

 So I propose to rename it to 0.19 because we have always evolved and
 never had any real revolution.

We had the transition to Unicode but missed it (version number wise).

 LyX 1.6.x is a different beast from 1.0.0 and yet you insist to have
 the same initial number. The change to a new major number is longer
 overdue.

In my view, it does not make sense to jump from 1.6 to 2.0. Even if
there are new features, there is also continuity in the base code.

I'd wait with 2.0 for the XML file format, as even if not seen by the
average user, this is a change at the very base and the numbe scheme
can serve to highlight this hidden revolution.

Günter

Re: XML?

[Guenter Milde]

On 2010-02-01, Steve Litt wrote:
 On Monday 01 February 2010 05:24:30 Vincent van Ravesteijn - TNW wrote:

 OK, I guess my question is this: If LyX were using
 LuaTex, what would my LyX document look like in Vim?

 I'd rather make sure you won't need vim anymore :).

 That's not gonna work. One of my reasons for switching to LyX was that I 
 *could* use Vim. A Vim-disabled LyX is just MS Word with better formatting.

While not using Vim but Jed, I second the statement that there are
task that are more efficiently be done in a text editor.

This is why I would greatly welcome improved support for external
editing of the lyx source:

* open file of current buffer in a configurable application,
  reload buffer once this application is closed.
  
* open a lyx file in LyX and jump to a specified place/line, so that I
  can easily go to `grep` results or the place I have been editing in
  my valued text editor.
  
Günter  

Re: XML?

[Tommaso Cucinotta]

Guenter Milde wrote:

This is why I would greatly welcome improved support for external
editing of the lyx source:

* open a lyx file in LyX and jump to a specified place/line, so that I
  can easily go to `grep` results or the place I have been editing in
  my valued text editor.
  
such use-case scenario would become much less likely to happen with 
Advanced Search, wouldn't it be ?


   T.

View - OpenDocument command produces empty output - help!

[0]

[examples/splash.lyx] is the document which automatically opens when user runs 
LyX first time after installation. The problem is that the View - 
OpenDocument command produces empty output for me. Please help!

OS: Windows XP
LyX: 1.6.5


  

RE: View - OpenDocument command produces empty output - help!

[Vincent van Ravesteijn - TNW]

[examples/splash.lyx] is the document which automatically opens when
user
runs LyX first time after installation. The problem is that the View -
OpenDocument command produces empty output for me. Please help!

Don't use OpenDocument. Use dvi or pdf to preview.

Vincent

RE: View - OpenDocument command produces empty output - help!

[0]

I want to send [examples/splash.lyx] to Bob. Bob hasn't LyX. And I would like 
Bob to be able to edit this document.

--- On Tue, 2/2/10, Vincent van Ravesteijn - TNW v.f.vanraveste...@tudelft.nl 
wrote:

 From: Vincent van Ravesteijn - TNW v.f.vanraveste...@tudelft.nl
 Subject: RE: View - OpenDocument command produces empty output - help!
 To: the_herd_of_the_hor...@yahoo.com, lyx-devel@lists.lyx.org, 
 lyx-us...@lists.lyx.org
 Date: Tuesday, February 2, 2010, 8:02 PM
 [examples/splash.lyx] is the
 document which automatically opens when
 user
 runs LyX first time after installation. The problem is
 that the View -
 OpenDocument command produces empty output for me.
 Please help!
 
 Don't use OpenDocument. Use dvi or pdf to preview.
 
 Vincent
 


  

Re: View - OpenDocument command produces empty output - help!

[0]

I want to send [examples/splash.lyx] to Bob. Bob hasn't LyX. And I would like 
Bob to be able to edit this document.


- Original Message 
From: Vincent van Ravesteijn - TNW v.f.vanraveste...@tudelft.nl
To: 0 the_herd_of_the_hor...@yahoo.com; lyx-devel@lists.lyx.org; 
lyx-us...@lists.lyx.org
Sent: Tue, February 2, 2010 8:02:15 PM
Subject: RE: View - OpenDocument command produces empty output - help!

[examples/splash.lyx] is the document which automatically opens when
user
runs LyX first time after installation. The problem is that the View -
OpenDocument command produces empty output for me. Please help!

Don't use OpenDocument. Use dvi or pdf to preview.

Vincent



  

Re: View - OpenDocument command produces empty output - help!

[0]

Yes, dvi and pdf work fine for me. But I want OpenDocument because I'm sending 
the file to another person and want him to be able to edit the file.





From: Vincent van Ravesteijn - TNW v.f.vanraveste...@tudelft.nl
To: 0 the_herd_of_the_hor...@yahoo.com; lyx-devel@lists.lyx.org; 
lyx-us...@lists.lyx.org
Sent: Tue, February 2, 2010 8:02:15 PM
Subject: RE: View - OpenDocument command produces empty output - help!

Don't use OpenDocument. Use dvi or pdf to preview.

Vincent

From: 0 the_herd_of_the_hor...@yahoo.com
To: lyx-devel@lists.lyx.org; 
lyx-us...@lists.lyx.org
Sent: Tue, February 2, 2010 7:53:25 PM
Subject: View - OpenDocument command produces empty output - help!

[examples/splash.lyx] is the document which automatically opens when 
user runs LyX first time after installation. The problem is that the 
View - OpenDocument command produces empty output for me. Please help! -- 0



  

RE: View - OpenDocument command produces empty output - help!

[Vincent van Ravesteijn - TNW]

 
  Yes, dvi and pdf work fine for me. But I want OpenDocument because 
 I'm sending the file to another person and want him to be able to edit
the file. 
 
I know, but don't send your answer SEVEN times ?!? 
 
Vincent

Re: View - OpenDocument command produces empty output - help!

[0]

The 1st email you could have received came to you only,while I wanted 
it come to the lists. Then, my answer came to two lists (developers and users) 
three times because that server was slow to display them at the mailing lists' 
archives - I thought it failed to receive them and made further attempts. I am 
sorry for this.I'll try to wait longer before making conclusions.

I am a LyX user and still would appreciate any help on my problem.





From: Vincent van Ravesteijn - TNW v.f.vanraveste...@tudelft.nl
To: 0 the_herd_of_the_hor...@yahoo.com; lyx-devel@lists.lyx.org
Sent: Tue, February 2, 2010 9:00:11 PM
Subject: RE: View - OpenDocument command produces empty output - help!

 
 
  Yes, dvi and pdf work fine for me. But I want 
OpenDocument because 
 I'm sending the file to another person and want 
him to be able to edit the file. 
 
I know, but 
don't send your answer SEVEN times ?!? 
 
Vincent


  

RE:

[0]

Export doesn't work - still empty output. 

I don't have RTF exporter, and I am afraid RTF can't export math... This is the 
main thing I am going to use LyX for - to make math documents and to send them 
to other people who should be able to edit the formulas.

=
Re: View - OpenDocument command produces empty output - help!
Rainer M Krug
Tue, 02 Feb 2010 04:09:51 -0800


Use the export functionality (might work), and possibly to RTF.



  

Re: View - OpenDocument command produces empty output - help!

[Liviu Andronic]

On 2/2/10, 0 the_herd_of_the_hor...@yahoo.com wrote:
  I am a LyX user and still would appreciate any help on my problem.

Exporting LyX/LaTeX to .doc/.odt/.rtf and the like can be problematic.
You can search the wiki and the archives for various experiences.
Liviu

Re: r33258 - in lyx-devel/trunk/src: . frontends frontends/qt4

[Peter Kümmel]

Am Sonntag, den 31.01.2010, 14:29 +0100 schrieb Andre Poenitz:
  How do we proceed now ?
 
 I think it's time to use signal/slots, this time in the right direction.
 The buffer emits a message, possibly with an indication that it is
 temporarily and the view (or the server...) connects to it.
 
 Andre'

Does this also mean currently we have no clear Model/View design?

Peter

Re: XML?

[Guenter Milde]

On 2010-02-02, Tommaso Cucinotta wrote:
 Guenter Milde wrote:
 This is why I would greatly welcome improved support for external
 editing of the lyx source:

 * open a lyx file in LyX and jump to a specified place/line, so that I
   can easily go to `grep` results or the place I have been editing in
   my valued text editor.

 such use-case scenario would become much less likely to happen with 
 Advanced Search, wouldn't it be ?

Prabably. I am not (yet) familiar with the power and usage of the new
interface. So I cannot tell whether it will be able to do regexp
replacements in math, say.

However, grep for a phrase in a set of lyx documents
(all papers of the last 3 years, say) is still a valid case.

Günter

Re: XML?

[Tommaso Cucinotta]

Guenter Milde wrote:
such use-case scenario would become much less likely to happen with 
Advanced Search, wouldn't it be ?


Prabably. I am not (yet) familiar with the power and usage of the new
interface. So I cannot tell whether it will be able to do regexp
replacements in math, say.
  
currently, it supports format- and regexp- enhanced search, and format- 
enhanced replace, e.g., you cannot back-reference found sub-patterns in 
your replacement text, however such extension should be feasible.



However, grep for a phrase in a set of lyx documents
(all papers of the last 3 years, say) is still a valid case.
  
sure, that's something at which grep is surely unbeatable and faster. On 
a related note, I was planning to implement a search scope in which all 
.lyx files within a folder are searched, this is something quite 
straightforward to be done in the current code base, however it will 
involve having LyX load all the files one by one, and doing the search, 
something which -- as said -- will be much slower than a grep. Anyway, I 
think an XML file-format would almost certainly preserve the grep 
ability, and within certain boundaries I guess also a regex-based replace.


   T.

Re: r33258 - in lyx-devel/trunk/src: . frontends frontends/qt4

[Andre Poenitz]

On Tue, Feb 02, 2010 at 02:53:58PM +0100, Peter Kümmel wrote:
 Am Sonntag, den 31.01.2010, 14:29 +0100 schrieb Andre Poenitz:
   How do we proceed now ?
  
  I think it's time to use signal/slots, this time in the right direction.
  The buffer emits a message, possibly with an indication that it is
  temporarily and the view (or the server...) connects to it.
  
  Andre'
 
 Does this also mean currently we have no clear Model/View design?

Sort of.

Right now the Gui is basically signaling the Core to change and the
Core pushes changes to the Gui. Which is pretty wrong.

Andre'

Re: r33258 - in lyx-devel/trunk/src: . frontends frontends/qt4

[Peter Kümmel]

Andre Poenitz wrote:
 On Tue, Feb 02, 2010 at 02:53:58PM +0100, Peter Kümmel wrote:
 Am Sonntag, den 31.01.2010, 14:29 +0100 schrieb Andre Poenitz:
 How do we proceed now ?
 I think it's time to use signal/slots, this time in the right direction.
 The buffer emits a message, possibly with an indication that it is
 temporarily and the view (or the server...) connects to it.

 Andre'
 Does this also mean currently we have no clear Model/View design?
 
 Sort of.
 
 Right now the Gui is basically signaling the Core to change and the
 Core pushes changes to the Gui. Which is pretty wrong.

You mean the core knows the gui and calls gui-only functions to
update the view? This would be indeed wrong.

Where there attempts to fix this design? Or was the design OK
in good old times and then somehow became wrong? Haven't Abdel
tried to cleanup this?

Shouldn't we do a cleanup/redesign at such places?

Peter

Re: Editing equations as latex rather than graphically.

[Tommaso Cucinotta]

Jean-Marc Lasgouttes wrote:
As far as I understand, the main point is to have the preview, right? 
Since this does not use the file conversion
stuff from insetexternal, I'd prefer indeed to have InsetPreview (or 
preview of ert) for these kind of uses.


I am not sure we want to advertise many ways of basically doing the 
same thing.
It might (just might) be for different use-case scenarios: if you have 
those very long, specially formatted equations, which you want to keep 
into their separate files (perhaps also for avoiding to modify them by 
mistake -- or because they're generated by some sort of scripting who 
knows from where), then you may want to insert them as external material.
If, instead, you're fine having that in the .lyx file, then you would 
use InsetERT.


I know one might use anyway an InsetERT which contains a simple 
\input{myformula}, but I don't know whether it would be a problem or 
not the fact that LyX would be unaware of the reference to the external 
file (e.g., it should be copied into the tmp foldere while compiling 
etc...).


   T.

Re: Editing equations as latex rather than graphically.

[Jean-Marc Lasgouttes]

Le 2 févr. 10 à 19:57, Tommaso Cucinotta a écrit :
It might (just might) be for different use-case scenarios: if you  
have those very long, specially formatted equations, which you want  
to keep into their separate files (perhaps also for avoiding to  
modify them by mistake -- or because they're generated by some sort  
of scripting who knows from where), then you may want to insert them  
as external material.
If, instead, you're fine having that in the .lyx file, then you  
would use InsetERT.


What I am wondering about is whether people actually do that.  
Everything we add has a price in terms of
making other things more difficult to find. In this sense it is better  
to merge features as much as possible
(for example it would make sense eventually to merge insetexternal and  
insetgraphics).


JMarc

Re: #6498: Regex looks like math.

[Tommaso Cucinotta]

Is it ok to add a ColorCode for a regexp frame like this ?

(what are all these strings ?)

Index: src/ColorCode.h
===
--- src/ColorCode.h(revisione 33318)
+++ src/ColorCode.h(copia locale)
@@ -196,6 +196,8 @@

/// Color is inherited
Color_inherit,
+/// Color for regexp frame
+Color_regexpframe,
/// For ignoring updates of a color
Color_ignore
};
Index: src/Color.cpp
===
--- src/Color.cpp(revisione 33318)
+++ src/Color.cpp(copia locale)
@@ -241,6 +241,7 @@
{ Color_buttonhoverbg, N_(button background under focus), 
buttonhoverbg, #C7C7CA, buttonhoverbg },
{ Color_paragraphmarker, N_(paragraph marker), paragraphmarker, 
grey80, paragraphmarker},

{ Color_inherit, N_(inherit), inherit, black, inherit },
+{ Color_regexpframe, N_(regexp frame), regexpframe, Green, 
regexpframe },

{ Color_ignore, N_(ignore), ignore, black, ignore },
{ Color_ignore, 0, 0, 0, 0 }
};


LyX Ticket Tracker wrote:

#6498: Regex looks like math.
+---
 Reporter:  gmatht  |   Owner:  lasgouttes
 Type:  defect  |  Status:  new   
 Priority:  low |   Milestone:
Component:  search  | Version:
 Severity:  minor   |Keywords:
+---

Changes (by sanda):

 * cc: tomm...@… (added)
  * component:  general = search


  

Re: r33318 - lyx-devel/trunk/src

[Vincent van Ravesteijn]

tomm...@lyx.org schreef:

Author: tommaso
Date: Tue Feb  2 21:36:12 2010
New Revision: 33318
URL: http://www.lyx.org/trac/changeset/33318
  

Hi Tommaso,

Yet again, I don't really understand your fix.

 
 	// Compute the match length

int len = 1;
+   if (cur.pos() + len  cur.lastpos())
+   return 0;
  

len is always 1 here ? Why the variable then ? Isn't this the same as
   cur.pos() == cur.lastpos() ?

Why do you have to explicitly check this ?

It looks especially peculiar, because exactly the same condition is 
there in the while loop below.



LYXERR(Debug::FIND, verifying unmatch with len =   len);
while (cur.pos() + len = cur.lastpos()  match(cur, len) == 0) {
++len;
  


When does it become a problem when cur.pos() + len  cur.lastpos ?

Vincent

Re: r33318 - lyx-devel/trunk/src

[Tommaso Cucinotta]

Vincent van Ravesteijn wrote:

tomm...@lyx.org schreef:

Author: tommaso
Date: Tue Feb  2 21:36:12 2010
New Revision: 33318
URL: http://www.lyx.org/trac/changeset/33318
  

Hi Tommaso,

Yet again, I don't really understand your fix.

my fault, I left it in the cryptic format in which I verified it to work.
 
 // Compute the match length

 int len = 1;
+if (cur.pos() + len  cur.lastpos())
+return 0;
  

len is always 1 here ? Why the variable then ? Isn't this the same as
   cur.pos() == cur.lastpos() ?

Why do you have to explicitly check this ?

It looks especially peculiar, because exactly the same condition is 
there in the while loop below.



 LYXERR(Debug::FIND, verifying unmatch with len =   len);
 while (cur.pos() + len = cur.lastpos()  match(cur, len) == 0) {
 ++len;
  


When does it become a problem when cur.pos() + len  cur.lastpos ?
the problem comes after the while(), because in the end it makes an 
attempt to putSelectionAt() with a length of 1, in a paragraph with a 
size of 0 (the bullet list (inset) with no contents).


Basically, I detect all that before it happens, and return.

However, I have to go through all the code, especially with 
ignore-format off, because I noticed some misbehaviour (probably some 
white-spaces more/less in the textual exports of insets -- w.r.t. a few 
months ago).


   T.

Re: XML?

[Steve Litt]

On Tuesday 02 February 2010 05:49:35 Tommaso Cucinotta wrote:
 Guenter Milde wrote:
  This is why I would greatly welcome improved support for external
  editing of the lyx source:
 
  * open a lyx file in LyX and jump to a specified place/line, so that I
can easily go to `grep` results or the place I have been editing in
my valued text editor.
 
 such use-case scenario would become much less likely to happen with
 Advanced Search, wouldn't it be ?
 
 T.

Here's a use case. Your doc no longer opens in LyX. So using Vim, you 
successively cut out parts of it until it opens in LyX again, and then back 
out the changes til you find the offending code. I've had that happen several 
times.

Another use case: VimOutliner to LyX converter. No matter how good the LyX 
outline mode gets (and it's getting great -- thanks everyone), VimOutliner 
will still be faster for slamming out outlines, just because it's based on Vim 
keystrokes rather than mouseclicking. So I created a VimOutliner to LyX 
converter. The more complex LyX code, the harder that is to do.

Another use case. My Troubleshooting Course Instructor Notes have one section 
per slide of the course. Each of these section headings announces its slide's 
page number. Whenever I add or subtract slides, all these sections have to be 
renumbered. No problem -- the page numbers are all blue, and I have a program 
that runs through the LyX native format and renumbers every blue number.

Perhaps the page numbering would have been better off done with some sort of 
counter attached to the sections. That's fine, but there's always another 
reason, and another, and yet another after that, to tweak with native format. 
There's ALWAYS going to be something LyX can't do, and direct file content 
editing gives me (and hundreds of others who take LyX beyond its intended 
usage) another way to do it.

It reminds me of free software. Only 1 out of 100 free software users is 
ready, willing and able to mess with the source code. And yet the fact that 
the source code CAN be messed with means you're never limited to just what the 
program can do -- you always have a way out of every mess. It may not be 
pretty, easy, or cheap, but you have a way out. The same thing's true of 
readable, parseable, writeable native formats.

In fact, editability was one of the reasons I chose LyX in the first place. 
Here's a quote from 
http://www.troubleshooters.com/tpromag/200109/200109.htm#_linuxlog:

The no exports problem turned out to be a paper tiger. After viewing a LyX 
document in VI it was obvious that it was simple, styles-based markup that 
could be easily manipulated, and yes, converted, with simple Perl scripts.

And here's a quote from 
http://www.troubleshooters.cxm/tpromag/200201/200201.htm#_TheDecision:

The decision came when I looked at a LyX document in VI. The LyX native file 
format is simple, easily understandable and parsable, and you can recover all 
styles. It would be trivial to write an app to convert LyX code to XML.

Never underestimate the power and desirability of a native format that's 
readable, parseable and writeable.

SteveT

Steve Litt
Recession Relief Package
http://www.recession-relief.US
Twitter: http://www.twitter.com/stevelitt

Re: XML?

[Pavel Sanda]

Guenter Milde wrote:
 This is why I would greatly welcome improved support for external
 editing of the lyx source:
 
 * open file of current buffer in a configurable application,
   reload buffer once this application is closed.

i feel this is task for only very advanced users and we shouldn't
promote editing lyx file directly in our gui.
as for your usecase, try: vc_command DR my-editor $$p/$$i

 * open a lyx file in LyX and jump to a specified place/line, so that I
   can easily go to `grep` results or the place I have been editing in
   my valued text editor.

not easy to do as discussed in bugzilla.

pavel

[patch] bug 6503: Including self as child document crashes branch

[Jürgen Spitzmüller]

http://www.lyx.org/trac/ticket/6503

This crash is caused by an infinite loop in Encodings::initMath, which 
recursively calls itself if a document includes itself (we already issue a 
warning about that, but in the given case, LyX crashes before the warning 
can be issued).

The fix is obviously to test whether child and parent are identical. I see 
two ways of doing this: either directly in the function (patch a) or 
upstream in Buffer::isChildren (patch b).

Which, if any, do you prefer?

Jürgen Index: src/Encoding.cpp
===
--- src/Encoding.cpp	(Revision 33282)
+++ src/Encoding.cpp	(Arbeitskopie)
@@ -557,7 +557,8 @@
 	BufferList::iterator bit = theBufferList().begin();
 	BufferList::iterator const bend = theBufferList().end();
 	for (; bit != bend; ++bit)
-		if (buffer.isChild(*bit))
+		// avoid recursive includes
+		if (buffer.isChild(*bit)  *bit != buffer)
 			initUnicodeMath(**bit, false);
 #endif
 }

Index: src/Buffer.cpp
===
--- src/Buffer.cpp	(Revision 33282)
+++ src/Buffer.cpp	(Arbeitskopie)
@@ -1804,6 +1804,9 @@
 
 bool Buffer::isChild(Buffer * child) const
 {
+	// avoid recursive includes
+	if (child == this)
+		return false;
 	return d-children_positions.find(child) != d-children_positions.end();
 }
 

Re: Editing equations as latex rather than graphically.

[Jean-Marc Lasgouttes]

Le 2 févr. 10 à 02:38, Tommaso Cucinotta a écrit :
This may be useful, for example, in case of mixed latex/lyx fans  
working at a paper, or for importing maths written previously in  
LaTeX keeping the original formatting/comments in a separate file.


I heard Vincent has an upcoming InsetPreview feature which I don't  
exactly know how would relate to this, perhaps both things may be  
worth to exist.


As far as I understand, the main point is to have the preview, right?  
Since this does not use the file conversion
stuff from insetexternal, I'd prefer indeed to have InsetPreview (or  
preview of ert) for these kind of uses.


I am not sure we want to advertise many ways of basically doing the  
same thing.


JMarc

RE: Editing equations as latex rather than graphically.

[Vincent van Ravesteijn - TNW]

>I heard Vincent has an upcoming InsetPreview feature which I don't
exactly
>know how would relate to this, perhaps both things may be worth to
exist.
>

Well, everything inside this Inset will get previewed. So if you put
your equation into an ert into this inset it will generate a preview of
the equation. This would only be necessary in cases which the math
editor does not handle. A common problem is math insets that need a
parameter e.g., xymatrix.

Vincent

Re: Goals for alpha 1

[Guenter Milde]

On 2010-02-01, José Matos wrote:
> On Friday 29 January 2010 22:38:05 Peter Kümmel wrote:

> So I propose to rename it to 0.19 because we have always evolved and
> never had any real revolution.

We had the transition to Unicode but missed it (version number wise).

> LyX 1.6.x is a different beast from 1.0.0 and yet you insist to have
> the same initial number. The change to a new major number is longer
> overdue.

In my view, it does not make sense to "jump" from 1.6 to 2.0. Even if
there are new features, there is also continuity in the base code.

I'd wait with 2.0 for the XML file format, as even if not seen by the
average user, this is a change at the very base and the numbe scheme
can serve to highlight this "hidden" revolution.

Günter

Re: XML?

[Guenter Milde]

On 2010-02-01, Steve Litt wrote:
> On Monday 01 February 2010 05:24:30 Vincent van Ravesteijn - TNW wrote:

>> >OK, I guess my question is this: If LyX were using
>> >LuaTex, what would my LyX document look like in Vim?

>> I'd rather make sure you won't need vim anymore :).

> That's not gonna work. One of my reasons for switching to LyX was that I 
> *could* use Vim. A Vim-disabled LyX is just MS Word with better formatting.

While not using Vim but Jed, I second the statement that there are
task that are more efficiently be done in a text editor.

This is why I would greatly welcome improved support for external
editing of the lyx source:

* open file of current buffer in a configurable application,
  reload buffer once this application is closed.
  
* open a lyx file in LyX and jump to a specified place/line, so that I
  can easily go to `grep` results or the place I have been editing in
  my valued text editor.
  
Günter  

Re: XML?

[Tommaso Cucinotta]

Guenter Milde wrote:

This is why I would greatly welcome improved support for external
editing of the lyx source:

* open a lyx file in LyX and jump to a specified place/line, so that I
  can easily go to `grep` results or the place I have been editing in
  my valued text editor.
  
such use-case scenario would become much less likely to happen with 
Advanced Search, wouldn't it be ?


   T.

"View - OpenDocument" command produces empty output - help!

[0]

[examples/splash.lyx] is the document which automatically opens when user runs 
LyX first time after installation. The problem is that the "View - 
OpenDocument" command produces empty output for me. Please help!

OS: Windows XP
LyX: 1.6.5


  

RE: "View - OpenDocument" command produces empty output - help!

[Vincent van Ravesteijn - TNW]

>[examples/splash.lyx] is the document which automatically opens when
user
>runs LyX first time after installation. The problem is that the "View -
>OpenDocument" command produces empty output for me. Please help!

Don't use OpenDocument. Use dvi or pdf to preview.

Vincent

RE: "View - OpenDocument" command produces empty output - help!

[0]

I want to send [examples/splash.lyx] to Bob. Bob hasn't LyX. And I would like 
Bob to be able to edit this document.

--- On Tue, 2/2/10, Vincent van Ravesteijn - TNW  
wrote:

> From: Vincent van Ravesteijn - TNW 
> Subject: RE: "View - OpenDocument" command produces empty output - help!
> To: the_herd_of_the_hor...@yahoo.com, lyx-devel@lists.lyx.org, 
> lyx-us...@lists.lyx.org
> Date: Tuesday, February 2, 2010, 8:02 PM
> >[examples/splash.lyx] is the
> document which automatically opens when
> user
> >runs LyX first time after installation. The problem is
> that the "View -
> >OpenDocument" command produces empty output for me.
> Please help!
> 
> Don't use OpenDocument. Use dvi or pdf to preview.
> 
> Vincent
> 


  

Re: "View - OpenDocument" command produces empty output - help!

[0]

I want to send [examples/splash.lyx] to Bob. Bob hasn't LyX. And I would like 
Bob to be able to edit this document.


- Original Message 
From: Vincent van Ravesteijn - TNW 
To: 0 ; lyx-devel@lists.lyx.org; 
lyx-us...@lists.lyx.org
Sent: Tue, February 2, 2010 8:02:15 PM
Subject: RE: "View - OpenDocument" command produces empty output - help!

>[examples/splash.lyx] is the document which automatically opens when
user
>runs LyX first time after installation. The problem is that the "View -
>OpenDocument" command produces empty output for me. Please help!

Don't use OpenDocument. Use dvi or pdf to preview.

Vincent



  

Re: "View - OpenDocument" command produces empty output - help!

[0]

Yes, dvi and pdf work fine for me. But I want OpenDocument because I'm sending 
the file to another person and want him to be able to edit the file.





From: Vincent van Ravesteijn - TNW 
To: 0 ; lyx-devel@lists.lyx.org; 
lyx-us...@lists.lyx.org
Sent: Tue, February 2, 2010 8:02:15 PM
Subject: RE: "View - OpenDocument" command produces empty output - help!

Don't use OpenDocument. Use dvi or pdf to preview.

Vincent

From: 0 
To: lyx-devel@lists.lyx.org; 
lyx-us...@lists.lyx.org
Sent: Tue, February 2, 2010 7:53:25 PM
Subject: "View - OpenDocument" command produces empty output - help!

[examples/splash.lyx] is the document which automatically opens when 
user runs LyX first time after installation. The problem is that the 
"View - OpenDocument" command produces empty output for me. Please help! -- 0



  

RE: "View - OpenDocument" command produces empty output - help!

[Vincent van Ravesteijn - TNW]

 
 > Yes, dvi and pdf work fine for me. But I want OpenDocument because 
> I'm sending the file to another person and want him to be able to edit
the file. 
 
I know, but don't send your answer SEVEN times ?!? 
 
Vincent

Re: "View - OpenDocument" command produces empty output - help!

[0]

The 1st email you could have received came to you only,while I wanted 
it come to the lists. Then, my answer came to two lists (developers and users) 
three times because that server was slow to display them at the mailing lists' 
archives - I thought it failed to receive them and made further attempts. I am 
sorry for this.I'll try to wait longer before making conclusions.

I am a LyX user and still would appreciate any help on my problem.





From: Vincent van Ravesteijn - TNW 
To: 0 ; lyx-devel@lists.lyx.org
Sent: Tue, February 2, 2010 9:00:11 PM
Subject: RE: "View - OpenDocument" command produces empty output - help!

 
 
 > Yes, dvi and pdf work fine for me. But I want 
OpenDocument because 
> I'm sending the file to another person and want 
him to be able to edit the file. 
 
I know, but 
don't send your answer SEVEN times ?!? 
 
Vincent


  

RE:

[0]

Export doesn't work - still empty output. 

I don't have RTF exporter, and I am afraid RTF can't export math... This is the 
main thing I am going to use LyX for - to make math documents and to send them 
to other people who should be able to edit the formulas.

=
Re: "View - OpenDocument" command produces empty output - help!
Rainer M Krug
Tue, 02 Feb 2010 04:09:51 -0800


Use the export functionality (might work), and possibly to RTF.



  

Re: "View - OpenDocument" command produces empty output - help!

[Liviu Andronic]

On 2/2/10, 0  wrote:
>  I am a LyX user and still would appreciate any help on my problem.
>
Exporting LyX/LaTeX to .doc/.odt/.rtf and the like can be problematic.
You can search the wiki and the archives for various experiences.
Liviu

Re: r33258 - in lyx-devel/trunk/src: . frontends frontends/qt4

[Peter Kümmel]

Am Sonntag, den 31.01.2010, 14:29 +0100 schrieb Andre Poenitz:
> > How do we proceed now ?
> 
> I think it's time to use signal/slots, this time in the right direction.
> The buffer emits a message, possibly with an indication that it is
> temporarily and the view (or the server...) connects to it.
> 
> Andre'

Does this also mean currently we have no clear Model/View design?

Peter

Re: XML?

[Guenter Milde]

On 2010-02-02, Tommaso Cucinotta wrote:
> Guenter Milde wrote:
>> This is why I would greatly welcome improved support for external
>> editing of the lyx source:

>> * open a lyx file in LyX and jump to a specified place/line, so that I
>>   can easily go to `grep` results or the place I have been editing in
>>   my valued text editor.

> such use-case scenario would become much less likely to happen with 
> Advanced Search, wouldn't it be ?

Prabably. I am not (yet) familiar with the power and usage of the new
interface. So I cannot tell whether it will be able to do regexp
replacements in math, say.

However, grep for a phrase in a set of lyx documents
(all papers of the last 3 years, say) is still a valid case.

Günter

Re: XML?

[Tommaso Cucinotta]

Guenter Milde wrote:
such use-case scenario would become much less likely to happen with 
Advanced Search, wouldn't it be ?


Prabably. I am not (yet) familiar with the power and usage of the new
interface. So I cannot tell whether it will be able to do regexp
replacements in math, say.
  
currently, it supports format- and regexp- enhanced search, and format- 
enhanced replace, e.g., you cannot back-reference found sub-patterns in 
your replacement text, however such extension should be feasible.



However, grep for a phrase in a set of lyx documents
(all papers of the last 3 years, say) is still a valid case.
  
sure, that's something at which grep is surely unbeatable and faster. On 
a related note, I was planning to implement a search scope in which all 
.lyx files within a folder are searched, this is something quite 
straightforward to be done in the current code base, however it will 
involve having LyX load all the files one by one, and doing the search, 
something which -- as said -- will be much slower than a grep. Anyway, I 
think an XML file-format would almost certainly preserve the "grep" 
ability, and within certain boundaries I guess also a regex-based replace.


   T.

Re: r33258 - in lyx-devel/trunk/src: . frontends frontends/qt4

[Andre Poenitz]

On Tue, Feb 02, 2010 at 02:53:58PM +0100, Peter Kümmel wrote:
> Am Sonntag, den 31.01.2010, 14:29 +0100 schrieb Andre Poenitz:
> > > How do we proceed now ?
> > 
> > I think it's time to use signal/slots, this time in the right direction.
> > The buffer emits a message, possibly with an indication that it is
> > temporarily and the view (or the server...) connects to it.
> > 
> > Andre'
> 
> Does this also mean currently we have no clear Model/View design?

Sort of.

Right now the Gui is basically signaling the Core to change and the
Core pushes changes to the Gui. Which is pretty wrong.

Andre'

Re: r33258 - in lyx-devel/trunk/src: . frontends frontends/qt4

[Peter Kümmel]

Andre Poenitz wrote:
> On Tue, Feb 02, 2010 at 02:53:58PM +0100, Peter Kümmel wrote:
>> Am Sonntag, den 31.01.2010, 14:29 +0100 schrieb Andre Poenitz:
 How do we proceed now ?
>>> I think it's time to use signal/slots, this time in the right direction.
>>> The buffer emits a message, possibly with an indication that it is
>>> temporarily and the view (or the server...) connects to it.
>>>
>>> Andre'
>> Does this also mean currently we have no clear Model/View design?
> 
> Sort of.
> 
> Right now the Gui is basically signaling the Core to change and the
> Core pushes changes to the Gui. Which is pretty wrong.

You mean the core knows the gui and calls gui-only functions to
update the view? This would be indeed wrong.

Where there attempts to fix this design? Or was the design OK
in good old times and then somehow became wrong? Haven't Abdel
tried to cleanup this?

Shouldn't we do a cleanup/redesign at such places?

Peter

Re: Editing equations as latex rather than graphically.

[Tommaso Cucinotta]

Jean-Marc Lasgouttes wrote:
As far as I understand, the main point is to have the preview, right? 
Since this does not use the file conversion
stuff from insetexternal, I'd prefer indeed to have InsetPreview (or 
preview of ert) for these kind of uses.


I am not sure we want to advertise many ways of basically doing the 
same thing.
It might (just might) be for different use-case scenarios: if you have 
those very long, specially formatted equations, which you want to keep 
into their separate files (perhaps also for avoiding to modify them by 
mistake -- or because they're generated by some sort of scripting who 
knows from where), then you may want to insert them as external material.
If, instead, you're fine having that in the .lyx file, then you would 
use InsetERT.


I know one might use anyway an InsetERT which contains a simple 
"\input{myformula}", but I don't know whether it would be a problem or 
not the fact that LyX would be unaware of the reference to the external 
file (e.g., it should be copied into the tmp foldere while compiling 
etc...).


   T.

Re: Editing equations as latex rather than graphically.

[Jean-Marc Lasgouttes]

Le 2 févr. 10 à 19:57, Tommaso Cucinotta a écrit :
It might (just might) be for different use-case scenarios: if you  
have those very long, specially formatted equations, which you want  
to keep into their separate files (perhaps also for avoiding to  
modify them by mistake -- or because they're generated by some sort  
of scripting who knows from where), then you may want to insert them  
as external material.
If, instead, you're fine having that in the .lyx file, then you  
would use InsetERT.


What I am wondering about is whether people actually do that.  
Everything we add has a price in terms of
making other things more difficult to find. In this sense it is better  
to merge features as much as possible
(for example it would make sense eventually to merge insetexternal and  
insetgraphics).


JMarc

Re: #6498: Regex looks like math.

[Tommaso Cucinotta]

Is it ok to add a ColorCode for a regexp frame like this ?

(what are all these strings ?)

Index: src/ColorCode.h
===
--- src/ColorCode.h(revisione 33318)
+++ src/ColorCode.h(copia locale)
@@ -196,6 +196,8 @@

/// Color is inherited
Color_inherit,
+/// Color for regexp frame
+Color_regexpframe,
/// For ignoring updates of a color
Color_ignore
};
Index: src/Color.cpp
===
--- src/Color.cpp(revisione 33318)
+++ src/Color.cpp(copia locale)
@@ -241,6 +241,7 @@
{ Color_buttonhoverbg, N_("button background under focus"), 
"buttonhoverbg", "#C7C7CA", "buttonhoverbg" },
{ Color_paragraphmarker, N_("paragraph marker"), "paragraphmarker", 
grey80, "paragraphmarker"},

{ Color_inherit, N_("inherit"), "inherit", "black", "inherit" },
+{ Color_regexpframe, N_("regexp frame"), "regexpframe", "Green", 
"regexpframe" },

{ Color_ignore, N_("ignore"), "ignore", "black", "ignore" },
{ Color_ignore, 0, 0, 0, 0 }
};


LyX Ticket Tracker wrote:

#6498: Regex looks like math.
+---
 Reporter:  gmatht  |   Owner:  lasgouttes
 Type:  defect  |  Status:  new   
 Priority:  low |   Milestone:
Component:  search  | Version:
 Severity:  minor   |Keywords:
+---

Changes (by sanda):

 * cc: tomm...@… (added)
  * component:  general => search


  

Re: r33318 - lyx-devel/trunk/src

[Vincent van Ravesteijn]

tomm...@lyx.org schreef:

Author: tommaso
Date: Tue Feb  2 21:36:12 2010
New Revision: 33318
URL: http://www.lyx.org/trac/changeset/33318
  

Hi Tommaso,

Yet again, I don't really understand your fix.

 
 	// Compute the match length

int len = 1;
+   if (cur.pos() + len > cur.lastpos())
+   return 0;
  

len is always 1 here ? Why the variable then ? Isn't this the same as
   "cur.pos() == cur.lastpos()" ?

Why do you have to explicitly check this ?

It looks especially peculiar, because exactly the same condition is 
there in the while loop below.



LYXERR(Debug::FIND, "verifying unmatch with len = " << len);
while (cur.pos() + len <= cur.lastpos() && match(cur, len) == 0) {
++len;
  


When does it become a problem when cur.pos() + len > cur.lastpos ?

Vincent

Re: r33318 - lyx-devel/trunk/src

[Tommaso Cucinotta]

Vincent van Ravesteijn wrote:

tomm...@lyx.org schreef:

Author: tommaso
Date: Tue Feb  2 21:36:12 2010
New Revision: 33318
URL: http://www.lyx.org/trac/changeset/33318
  

Hi Tommaso,

Yet again, I don't really understand your fix.

my fault, I left it in the cryptic format in which I verified it to work.
 
 // Compute the match length

 int len = 1;
+if (cur.pos() + len > cur.lastpos())
+return 0;
  

len is always 1 here ? Why the variable then ? Isn't this the same as
   "cur.pos() == cur.lastpos()" ?

Why do you have to explicitly check this ?

It looks especially peculiar, because exactly the same condition is 
there in the while loop below.



 LYXERR(Debug::FIND, "verifying unmatch with len = " << len);
 while (cur.pos() + len <= cur.lastpos() && match(cur, len) == 0) {
 ++len;
  


When does it become a problem when cur.pos() + len > cur.lastpos ?
the problem comes after the while(), because in the end it makes an 
attempt to putSelectionAt() with a length of 1, in a paragraph with a 
size of 0 (the bullet list (inset) with no contents).


Basically, I detect all that before it happens, and return.

However, I have to go through all the code, especially with 
ignore-format off, because I noticed some misbehaviour (probably some 
white-spaces more/less in the textual exports of insets -- w.r.t. a few 
months ago).


   T.

Re: XML?

[Steve Litt]

On Tuesday 02 February 2010 05:49:35 Tommaso Cucinotta wrote:
> Guenter Milde wrote:
> > This is why I would greatly welcome improved support for external
> > editing of the lyx source:
> >
> > * open a lyx file in LyX and jump to a specified place/line, so that I
> >   can easily go to `grep` results or the place I have been editing in
> >   my valued text editor.
> 
> such use-case scenario would become much less likely to happen with
> Advanced Search, wouldn't it be ?
> 
> T.

Here's a use case. Your doc no longer opens in LyX. So using Vim, you 
successively cut out parts of it until it opens in LyX again, and then back 
out the changes til you find the offending code. I've had that happen several 
times.

Another use case: VimOutliner to LyX converter. No matter how good the LyX 
outline mode gets (and it's getting great -- thanks everyone), VimOutliner 
will still be faster for slamming out outlines, just because it's based on Vim 
keystrokes rather than mouseclicking. So I created a VimOutliner to LyX 
converter. The more complex LyX code, the harder that is to do.

Another use case. My Troubleshooting Course Instructor Notes have one section 
per slide of the course. Each of these section headings announces its slide's 
page number. Whenever I add or subtract slides, all these sections have to be 
renumbered. No problem -- the page numbers are all blue, and I have a program 
that runs through the LyX native format and renumbers every blue number.

Perhaps the page numbering would have been better off done with some sort of 
counter attached to the sections. That's fine, but there's always another 
reason, and another, and yet another after that, to tweak with native format. 
There's ALWAYS going to be something LyX can't do, and direct file content 
editing gives me (and hundreds of others who take LyX beyond its intended 
usage) another way to do it.

It reminds me of free software. Only 1 out of 100 free software users is 
ready, willing and able to mess with the source code. And yet the fact that 
the source code CAN be messed with means you're never limited to just what the 
program can do -- you always have a way out of every mess. It may not be 
pretty, easy, or cheap, but you have a way out. The same thing's true of 
readable, parseable, writeable native formats.

In fact, editability was one of the reasons I chose LyX in the first place. 
Here's a quote from 
http://www.troubleshooters.com/tpromag/200109/200109.htm#_linuxlog:

"The "no exports" problem turned out to be a paper tiger. After viewing a LyX 
document in VI it was obvious that it was simple, styles-based markup that 
could be easily manipulated, and yes, converted, with simple Perl scripts."

And here's a quote from 
http://www.troubleshooters.cxm/tpromag/200201/200201.htm#_TheDecision:

"The decision came when I looked at a LyX document in VI. The LyX native file 
format is simple, easily understandable and parsable, and you can recover all 
styles. It would be trivial to write an app to convert LyX code to XML."

Never underestimate the power and desirability of a native format that's 
readable, parseable and writeable.

SteveT

Steve Litt
Recession Relief Package
http://www.recession-relief.US
Twitter: http://www.twitter.com/stevelitt

Re: XML?

[Pavel Sanda]

Guenter Milde wrote:
> This is why I would greatly welcome improved support for external
> editing of the lyx source:
> 
> * open file of current buffer in a configurable application,
>   reload buffer once this application is closed.

i feel this is task for only very advanced users and we shouldn't
promote editing lyx file directly in our gui.
as for your usecase, try: vc_command DR "my-editor $$p/$$i"

> * open a lyx file in LyX and jump to a specified place/line, so that I
>   can easily go to `grep` results or the place I have been editing in
>   my valued text editor.

not easy to do as discussed in bugzilla.

pavel

[patch] bug 6503: Including self as child document crashes branch

[Jürgen Spitzmüller]

http://www.lyx.org/trac/ticket/6503

This crash is caused by an infinite loop in Encodings::initMath, which 
recursively calls itself if a document includes itself (we already issue a 
warning about that, but in the given case, LyX crashes before the warning 
can be issued).

The fix is obviously to test whether child and parent are identical. I see 
two ways of doing this: either directly in the function (patch a) or 
upstream in Buffer::isChildren (patch b).

Which, if any, do you prefer?

Jürgen Index: src/Encoding.cpp
===
--- src/Encoding.cpp	(Revision 33282)
+++ src/Encoding.cpp	(Arbeitskopie)
@@ -557,7 +557,8 @@
 	BufferList::iterator bit = theBufferList().begin();
 	BufferList::iterator const bend = theBufferList().end();
 	for (; bit != bend; ++bit)
-		if (buffer.isChild(*bit))
+		// avoid recursive includes
+		if (buffer.isChild(*bit) && *bit != )
 			initUnicodeMath(**bit, false);
 #endif
 }

Index: src/Buffer.cpp
===
--- src/Buffer.cpp	(Revision 33282)
+++ src/Buffer.cpp	(Arbeitskopie)
@@ -1804,6 +1804,9 @@
 
 bool Buffer::isChild(Buffer * child) const
 {
+	// avoid recursive includes
+	if (child == this)
+		return false;
 	return d->children_positions.find(child) != d->children_positions.end();
 }