Re: LyX/Win 1.4.0

[Lars Gullik Bjønnes]

Angus Leeming [EMAIL PROTECTED] writes:

| Grab it from:
| http://wiki.lyx.org/uploads/Windows/LyX140pre/lyx-1.4.0pre_win32_setup_v1.exe
| 
| I anticipate that the installer will have the same bugs as the 1.3.x
| version since the installer code is little different to the previous
| version. (The one real change being that I've removed all tests for
| Perl in the installer.)

Does this contain changes that you want to commit to the repo? If so
please do so that I can spin pre6.

-- 
Lgb

Re: DVI search.

[Lars Gullik Bjønnes]

João Luis Meloni Assirati [EMAIL PROTECTED] writes:

| Index: src/LaTeX.C
| ===
| --- src/LaTeX.C   (revision 13280)
| +++ src/LaTeX.C   (working copy)
| @@ -383,7 +383,8 @@
|  
|  int LaTeX::startscript()
|  {
| - string tmp = cmd + ' ' + QuoteName(file) ++ os::nulldev();
| + string tmp = cmd + (runparams.srcspecials?(' ' + 
lyxrc.source_specials_switch):) +
| + ' ' + QuoteName(file) ++ os::nulldev();

ostringstream perhaps? At least use temps/foramtting to make the line
look nicer.

| Index: src/converter.h
| ===
| --- src/converter.h   (revision 13280)
| +++ src/converter.h   (working copy)
| @@ -137,7 +138,7 @@
|std::string const  filename);
|   ///
|   bool runLaTeX(Buffer const  buffer, std::string const  command,
| -   OutputParams const );
| +   std::string const  name, OutputParams const );

Why not add the name to the OutputParams?
Is 'name' a nice name for this parameter?

|   ///
|   ConverterList converterlist_;
|   ///
| Index: src/lyxrc.C
| ===
| --- src/lyxrc.C   (revision 13280)
| +++ src/lyxrc.C   (working copy)
| @@ -280,6 +282,8 @@
|   preview = PREVIEW_OFF;
|   preview_hashed_labels  = false;
|   preview_scale_factor = 0.9;
| + source_specials_switch = ;
| + dvi_fwsearch_switch = ;

Not needed.

| Index: src/texrow.C
| ===
| --- src/texrow.C  (revision 13280)
| +++ src/texrow.C  (working copy)
| @@ -78,6 +78,39 @@
|  }
|  
|  
| +int TexRow::getRowFromId(int id, int pos) const
| +{
| + RowList::const_iterator cit = rowlist.begin();
| + int diff_id = abs(cit-id() - id);
| + int best_id = cit-id();
| + int diff_pos = abs(cit-pos() - pos);
| + int best_row = cit-rownumber();
| + while (cit != rowlist.end()) {
| + ++cit;

This looks wrong. If cit == rowlist.end() - 1, then ++cit will bring
it to rowlist.end() and all operations on it will be bogus.

Please also change to use a for loop and don't reevaluate
rowlist.end() on each iteration.

-- 
Lgb

Re: DVI search.

[Lars Gullik Bjønnes]

João Luis Meloni Assirati [EMAIL PROTECTED] writes:

| Index: src/texrow.h
| ===
| --- src/texrow.h  (revision 13280)
| +++ src/texrow.h  (working copy)
| @@ -46,6 +46,9 @@
|*/
|   bool getIdFromRow(int row, int  id, int  pos) const;
|  
| + /// getRowFromId - find the closest row for a given (id, pos) pair
| + int TexRow::getRowFromId(int id, int pos) const;
| +

This 'TexRow::' is actually a syntax error and will give warning/error
with gcc 4.1.

Note also that I plan to get rid of TexRow completely later, infavour
of unique id's on paragraphs and offsets into the paragraph. Then we
can have dvi files that can contain sourcespecials and we can send
them around and expect the reverse search to work.

-- 
Lgb

Re: LyX/Win 1.4.0

[Angus Leeming]

Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
 | I anticipate that the installer will have the same bugs as the 1.3.x
 | version since the installer code is little different to the previous
 | version. (The one real change being that I've removed all tests for
 | Perl in the installer.)

 Does this contain changes that you want to commit to the repo?

Yes.

 If so please do so that I can spin pre6.

I'm afraid that I can't. When I try and pull over a copy of the repository onto
my Windows box using svn+ssh:

* with TortoiseSVN I get an infinite repeat of dialogs asking for my password.
* using either Cygwin's or the native Windows svn command line, the thing just
hangs. They shouldn't need my password as I have my ssh keys set up (can log on
to aussie with ssh without being prompted for a password).

Interestingly, I did pull over the 1.3.x branch onto my *linux* box using
svn+ssh, so the problem is at my end and with my Windows box rather than at your
end.

The net result is that I finally pulled over the repo using anonsvn; no write
access.

So, could you commit this patch to both the 1.4 branch and to head for me
please? It isn't perfect but it's a monotonic improvement over what exists
currently. I'll try and find some time to tweak it thereafter.

Of course, if you don't commit the patch, that isn't a big deal and shouldn't
hold up pre6. This patch is an update of some build scripts for Windows (I think
of them as both private to me and as a guide to Joe Public) and for the
Installer that is essentially orthogonal to LyX itself. Your call whether
they're needed for pre6.

Angus

Re: Lyx/Win does not accept characters in non-english encoding!

[Angus Leeming]

Stephen Harris [EMAIL PROTECTED] writes:
 Angus wrote:
 Ok, you can grab this iconv-aware version of LyX 1.3.7 here:
 http://wiki.lyx.org/uploads/Windows/LyX137/lyx-1.3.7_win32_setup_v3.exe

 This is probably not what is supposed to be tested, but
 the spellchecker fails The spellchecker has failed! No word
 lists can be found for the language en.

As yo suggest, this is all to do with the aspell 0.5 to 0.6 change. aspell 0.6
expects to find its dictionaries in a different location to 0.5. Haven't got
time to help here I'm afraid but the aspell pages are quite explicit (as you
pointed out), so it'd be great if you could install dictionaries in the place
expected by aspell 0.6 and see if you can spell check both flavours of LyX at
the same time.

That's the sort of release info we'll need to add to the LyX137 page on the
wiki if we eventually go with this _v3.

Angus

ps, as you say, the real reason for posting this thing was for code-page
competent individuals to play with gettext. That's still the case...

A.

Re: LyX/Win 1.4.0

[Angus Leeming]

Stephen Harris [EMAIL PROTECTED] writes:
 Angus wrote:
 I anticipate that the installer will have the same bugs as the 1.3.x 
 version since the installer code is little different to the previous 
 version. (The one real change being that I've removed all tests for 
 Perl in the installer.) 

 I got an error message during the install: Failed attempting to set
 path_prefix in the configure script. And there were no entries in
 Path prefix when I checked under Preferences later.

Right. This is my bad. The support files have changed location (from
Resources/lyx/ to Resources/) and the installer is looking in the old location.
FWIW, I saw this too but it was late, I was tired and I fixed it in the same
way that you did :)

Lars, this shouldn't stop you committing the patch :) Please do so and I'll
provide a tweak to the installer thereafter.

Angus

Re: Lyx/Win does not accept characters in non-english encoding!

[Angus Leeming]

Angus Leeming [EMAIL PROTECTED] writes:
 As yo suggest, this is all to do with the aspell 0.5 to 0.6 change. aspell 0.6
 expects to find its dictionaries in a different location to 0.5. Haven't got
 time to help here I'm afraid but the aspell pages are quite explicit (as you
 pointed out), so it'd be great if you could install dictionaries in the place
 expected by aspell 0.6 and see if you can spell check both flavours of LyX at
 the same time.

Forgot to add: you can grab dictionaries from
ftp://ftp.gnu.org/gnu/aspell/dict/
E.g.
ftp://ftp.gnu.org/gnu/aspell/dict/en/aspell6-en-6.0-0.tar.bz2
ftp://ftp.gnu.org/gnu/aspell/dict/de/aspell6-de-20030222-1.tar.bz2
ftp://ftp.gnu.org/gnu/aspell/dict/fr/aspell-fr-0.50-3.tar.bz2

My reading of the aspell pages is that aspell 0.6 is perfectly happy with the
0.5 dictionaries so long as they're installed in the expected place.

Angus

Re: DVI search.

[Angus Leeming]

João Luis Meloni Assirati [EMAIL PROTECTED] writes:
  * if LyX were able to talk to xdvi through the lyxclient interface, then we
  wouldn't have to keep creating a new xdvi process in client mode each
  time I click in the LyX window which is what happens now.
 
 No. We don't create a new xdvi process each time we click in the lyx window.
 View - DVI remains the only way to start a new xdvi process. Forward search 
 means that this new xdvi will start at the right page. What occours now is 
 that xdvi is called with the option

Sorry to be pedantic, but from LyX's point of view that's creating a new xdvi
isn't it? I.e., your xdvi is called is my 'system(xdvi option1 option2);'.
Or, eventually, when system() is consigned to the waste bin of history we'll be
using fork() and 'execvp(xdvi, [xdvi, option1, option2, 0]);'

What xdvi itself does with this is a separate matter. (Whether a whole new and
fully-functional instance of xdvi is created or whether the newly created
process just posts the new info to an existing, running xdvi client for it to
update its data.)

Anyway, the whole discussion is just for my academic interest, so don't let my
pedantry bother you :)

 There is also a high level tool to communicate with xdvi, which is xdvi 
 itself 
 (i.e., there is no xdviclient; instead, xdvi itself can work in client mode). 
 It communicates with another running xdvi not through a socket like we do, 
 but through something called X properties, a native xwindow message passing 
 protocol (the same way emacsclient and 'mozilla -remote' do 
 (http://www.mozilla.org/unix/remote.html)).

Interesting. Thanks. FWIW it appears that Windows apps tend to use a similar
technique to prevent multiple instances of an app from running simultaneously.

  I think that this is a great piece of work
  and think it should have gone into the LyX sources a long, long time ago.

 Thanks for the kind words, Angus. I am a theoretical physicist, not a 
 programmer, and all I know about C++ comes from hacking parts of the lyx code 
 and reading some online references in www.lyx.org/devel/references.php.

That sounds like the same route I took into LyX :)

 For me and some of my colleagues, lyx and a web browser are
 the most important software, so I hack lyx because it is
 important to me, in those parts that I think are important to me.
 Therefore I think it is natural that my contributions are not priority.

Well, it seems to me that we've raised the entry bar too high. LyX survives on
contributers like yourself and we should make it easy for them to feel like
insiders. I'm guessing that etting your code into the repo in less than two
years would have helped enormously to make you feel like an insider :)

  Very well :) http://www.lyx.org/~leeming/William/
 
 Beautiful. You are a coruja (owl) like we say in Brazil, meaning a very 
 proud and loving dad (applies to a mom, too)  :).

Less loving this morning as the wee bugger kept us up all night for no good
reason. Pushing at boundaries already :)

Angus

Re: Bugzilla 2315

[Georg Baum]

Lars Gullik Bjønnes wrote:

 
 This is still not resolved as fixed in bugzilla, shouldn't it be?

No, since the fix is not applied (2315 is not about the mathbb problem, but
about converting stuff to math by C-M). I had no time to test the fix
thoroughly, the current state is that Jürgen tested the patch and found no
problems.


Georg

lyx140cvn: longer error messages

[Hartmut Haase]

If in 
src/converter.C:442 src/format.C:265 src/format.C:310
50 would be replaced by e.g. 80 or more longer text strings could be 
displayed.
E.g. latex2html -no_subdir -split 0 -show_section_numbers $$i
has already 55 characters without the file.
-- 
Viele Grüße,
Hartmut Haase

Hungerhilfe: http://www.thehungersite.com

Das heutige Motto:
Beam me up, Scotty. There's no intelligent life down here. 

Re: Trying to use Mingw and Cygwin without Msys

[Enrico Forestieri]

Abdelrazak Younes [EMAIL PROTECTED] writes:
 
 Hello,
 
 I spent an awful lot of time trying to fix my msys install without
 success so I decided to give cygwin a try. There is a way to use cygwin
 environment with mingw without the -mno-cygwin option (see the mingw FAQ
 at the end of this email). The goal is to produce a package that will
 not need cygwin to run.

Hi Abdel,

I use cygwin with the -mno-cygwin option to build a LyX package which runs
without needing cygwin. I paste at the bottom an uuencoded tar archive
with my notes and a couple of scripts which are modified versions of
similar scripts by Angus. The procedure works for me without a glitch.

To extract the archive simply save this post in a file and run uudecode
on it (cygwin is your friend here):

 uudecode -o lyxwin.tar.gz name_of_saved_file

Please, note that I have not installed MinGW for the simple reason that
when you use the -mno-cygwin option you are really using the MinGW
compiler ;-)

In the notes you are instructed to create a C:\MinGW dir which is then
populated during the procedure. You can choose whatever name for that
dir (C:\Aspell, perhaps) but remember to accordingly change every
occurrence of it.

-- 
Enrico


begin 644 lyxwin.tar.gz
M'XL(`)S_!D0``^Q;ZW?32+*?K]?G\#_TB#!.P)+\2`)X2,Z$)$#.F`22L,!9
M[WIDJ6UKT2MZQ/$P_._W5_V09,!V3V7V2_7X-CJKJZN5U=75;#Q8T;AXD?
MN_R7_X+J\V7KO;V_39;S3%I_M[8YH;[=[[5VTH:'=V7G\'L')UNK[OS
M`VM_'W*67T66.REC/_#)M^!XFOT5!/VUKX[%7OO1R_?L)S;O=9W$9^YB.OC
MECCN)V?*LWN-XV.U6$'9OS9A`P(+E,Z[AE/6D;.[G,V:46S*GA8+G4^
M944*^)C-GM^K\'PH$$%P[J1\70O]:#IG3N3=00';C`8HP3B8%%5CB!
MQ.7Q:Q[$2BC')/$0;;5(I(97Z8!`OFIMS));VGW(WC],%.^S;@F=[[$?$
M'B':8.$G0#`S6=M](F[EMAIL PROTECTED]US,G44FI.%HBK,9!V^;8R;[EMAIL PROTECTED]
M2S`6Q3ES0\_B-TH113P+`/)@$=W,?B#87$BSCT2%68U@@9Y\7
MT2?%BEH(,P2V[CP`X]:WN8MEG'.QA#*?,MB!R'[EMAIL PROTECTED]3H0!'9+)Y'8$,2
MU\+(G/GX#U)2_]K78L7T+J0]%9(+!3PQ!5MQ?)#24F.4D!UH.L^AH7@=8^S
MW,^+'.1(7`:_2(T9Q\^?-C[^/CP4BU@-R`CRGO/HFCH9=5K2W+KL,I;F
[EMAIL PROTECTED])[]T%A=0NSF!QICMZG:?5`7BH)X6/:QH9PZIPHXUQ4*
[EMAIL PROTECTED]/8PSXL#_,[EMAIL PROTECTED];?R8#+AN!,LNYXQ'U-#J,(5:W,=P#X`!
M[+J09:\/DBP9?X?OPAGUV(#?^S#*J[E8X=0-!#`*7#%:O)C9)XU`R-LOS
MI_;\_GFD:%%:=3$#S)Y[`3\JAT)M?UJS/[EMAIL PROTECTED],UH0FWT+;@/:WI[W+R
M+CN^R5/'S7]-:S0OQVD:5V$+M.8I:XM5+X?UV*%T(F*MD'S)100UOJ2^
M76]Y;MUNV7I5'9XN-NF[=$379(4RO.7WT:*7UQ[EMAIL PROTECTED]5TSSKI#ZHVGR
MR!D'W`0MN0]TIN=GLF$^7BUABC(\)2D?.+?[G?49HH;+C^77/WORAAS6?
M)5Q.T/NF-63'+0E.*D%?'UD*736;;VFU;VZ6NJYY=R,GM=JF-(3Q[]WE
M7C\W81:C;[EMAIL PROTECTED],*3QB4]NZBNFTA.FHE7ME(R6YK%$KFY7+N;-
MP4K9F!5ELZ]OT%MQE]A1H#L=V4$U,YM?S[%D;[JUG:O[(WSXZR1Y;;,W
M3N[.:)[EMAIL PROTECTED][EMAIL 
PROTECTED]/+31*QVE2'Y)Q:M3QA4M'P4_X4_1#I=MFIV-V=EBG
MU^\^[]L6VW]8H\0X:GU^0@6SN]I%MF)VNV6NS+A#M]K[ZQ'[EMAIL PROTECTED]
M7?8(?Q_C438S]7'?GWA\PMZ?G/;(-7D]VE#(/X\QP,G?DTAYBS9+$T,,J
M@=^;,WVJW:@\R/[EMAIL PROTECTED]/CR\NV$AN6NS4(L;$EXE62TYS7-[U^QV6?MQ
MO]?M]]I+/'?7*]5!=:A[6W^]UV?Z=]M]VNR0T_%TG-T/\YR!$MA739:
MAD5$DDT0=.03/5`)Y^CXQ[P5H'#Z$EM]-'IWL3R:V38[/;[EMAIL PROTECTED]@
M`H4D]^-(AB11/[EMAIL PROTECTED]:,B6DP:\68Z_B.:*\E1+)KVS=K=8=09?
M[P]:WM#ADEND0:0E,9^I:NQ;+L59WQG%\_IU]YR?_6]K%ML;7/5M'
M1]2Q)+'GD\2D=T=]I++W3U`7)WE[/!O%PS*R11$R=VRU]QQ1AT?G9VR8Q^
[EMAIL PROTECTED]+Q'/9+^YU9F5QD;H44TV[4M]8QG%N7^58:Z7#1BL+XBE%
MZ=3P+.5YD4;[;#.*L%EV3Q.O:TZL/G[4ZPF9J;@B0Q:B'?\_/#TX/7S'3
MN\I[[HWTS9+W'51Y4TBUATJ?3OL!J49L7BT9-HO@'/!C[+)9@,!9;MY
M+E1+2U$YBY/2)HQ0OW023_1N(!6%P)`73AD.[EMAIL PROTECTED];S6.74NB?T,[R
M0OL;@)CCTTBM_.Q;P$D:3U,XOJ_`79$`UO9+B!?('V@)+TI),67_.6C-0I
M'A]CZ41;I*PLK1;MY.L%KU=[EMAIL PROTECTED]OZS.2LF=G#X7#S[__^,=PRQ[:
MPXX];;)G%./\GC_3E;DWTLD6C)[EMAIL PROTECTED]V1J2,;@NV+7+5+*Q;:D\R?
M*%:+HIX2I\/#%H4%^//[EMAIL PROTECTED]/37Z6K6[8GL)^5W!PXL\6XE!5!^2)I;
MCD14'R:YJT],O*:O3'$=9'31-.5FC;O4JU@[EMAIL PROTECTED]:[EMAIL PROTECTED]/
MU42691G(7'VLH+`OX969).X=8VK$B?:PNIS$+F%)\*MW(4$9FK,8O
M_D18+_Q,$S9/7[[!G,9=\04IX8-4)-B+DM)1?N[$'8_0M;[EMAIL PROTECTED]
M__A#C6XQJ7397;?HA.D+*B@@903:$+_Y5Q2K^S,I%VXV1A[KM)U82F/MI
MB/6?NY9T,CWA9ODGEMC)R_#,ZIMQ,C3-\+D3B3K1C]/A.9-.+W2*6BH?)U
MPCO#BV!AS;@KG`K9H:[*5NL-#8@@\P!UO#D^?,#V]FKN;;.$8NI3QIR
M0*DF+\9T)'3XW$\M.7XDYA4RG=YO/'@[71R?F#(;F7(5:,1^NR_)HIQ'
M1;`\$D3R-([EMAIL PROTECTED]'YAEV'$RIY(',!$M8UJTW`RJXK$?`W5ELW=VE
MV%_B62YH)0VS/CZB\`3Y1S)F,[EMAIL PROTECTED]/XVO^E3F$M=P+)4[EMAIL 
PROTECTED],[EMAIL PROTECTED]
M.00$G*++$F)C$*Q/@BDZH/IW=P,HWSF!V?GY^=KXBF?-R2QJESB/`3
MPA4WLTO#L(5SL,AJ6RR,/7^R(/3M3TB,2-SDT4G49-2M-07QNV-4E1BBTJ
MD)$9S9W4T]MFN1T*:QT)/UE[W[EMAIL PROTECTED]@MO^6!#\_?%P=A-F
[EMAIL PROTECTED],[EMAIL PROTECTED]@;'%4@:KH`OOIUA,4S.OYPG%Y02#*6RU-
M]2M`EJ=2Q4VIT1VE4G93!9H2RHCGCH(RY6^91([EMAIL PROTECTED])'P;F:%2[L8
M.2NF1LQZ]V;#YC3;M)1BJ:QE/'(%55]$D'OBOYKYMXU;2`BGTQ81:/,
MHJIG=9[NNOBK3RR8OM,`/7[8'V$F2$[EMAIL PROTECTED]/EE_VYHFX[EMAIL PROTECTED]
MG62=-TGW3HU;R]R4;,EN;PA4R5$\*W)T4^(@4]8F^/_+3?+^6TN84VG.*
MY;\C^+[EMAIL PROTECTED]:NWLLRI!VT6THE\!=\T].IX#ALS6H8Y!KX!JL
M_9LT0#W2GJ_PRIE7)1-]YL#H?-%LRJ-HVTZUWMJ9:CX=#QI7G#Z2AC1;IA
MYC/[EMAIL PROTECTED]JY,7$0WTENSRX/[EMAIL PROTECTED]()JAC/T;$YQ1!OF4A

Re: Bugzilla 2315

[Lars Gullik Bjønnes]

Georg Baum [EMAIL PROTECTED] writes:

| Lars Gullik Bjønnes wrote:
| 
|  
|  This is still not resolved as fixed in bugzilla, shouldn't it be?
| 
| No, since the fix is not applied (2315 is not about the mathbb problem, but
| about converting stuff to math by C-M). I had no time to test the fix
| thoroughly, the current state is that Jürgen tested the patch and found no
| problems.

Then someone have to test it promptly or this will not be in 1.4.0.

-- 
Lgb

Re: Bugzilla 2315

[Georg Baum]

Lars Gullik Bjønnes wrote:

 Then someone have to test it promptly or this will not be in 1.4.0.

OK, here is an updated patch for testing (nothing had changed, I only moved
the ChangeLog entry). Any takers?


GeorgIndex: src/ChangeLog
===
--- src/ChangeLog	(Revision 13280)
+++ src/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,7 @@
+2006-02-26  Georg Baum  [EMAIL PROTECTED]
+
+	* text3.C (mathDispatch): fix math inset creation from string (bug 2315)
+
 2006-02-28  Martin Vermeer  [EMAIL PROTECTED]
 
 	* cursor.C (niceInsert): fix (properly) insertion of
Index: src/text3.C
===
--- src/text3.C	(Revision 13280)
+++ src/text3.C	(Arbeitskopie)
@@ -158,16 +158,17 @@ namespace {
 			// create a macro if we see \\newcommand
 			// somewhere, and an ordinary formula
 			// otherwise
+			istringstream is(sel);
 			if (sel.find(\\newcommand) == string::npos
 			 sel.find(\\def) == string::npos)
 			{
-cur.insert(new MathHullInset(simple));
-cur.dispatch(FuncRequest(LFUN_RIGHT));
-cur.dispatch(FuncRequest(LFUN_INSERT_MATH, sel));
-			} else {
-istringstream is(sel);
+MathHullInset * formula = new MathHullInset;
+LyXLex lex(0, 0);
+lex.setStream(is);
+formula-read(cur.buffer(), lex);
+cur.insert(formula);
+			} else
 cur.insert(new MathMacroTemplate(is));
-			}
 		}
 		cur.message(N_(Math editor mode));
 	}

Re: Trying to use Mingw and Cygwin without Msys

[Enrico Forestieri]

Enrico Forestieri [EMAIL PROTECTED] writes:

 I use cygwin with the -mno-cygwin option to build a LyX package which runs
 without needing cygwin. I paste at the bottom an uuencoded tar archive

I just noticed that this damn'd gmane interface horribly mangled the
uuencoded archive. I am posting it again using base64 encoding this time.
Same procedure as before for axtracting it.

-- 
Enrico


begin-base64 644 lyxwin.tar.gz
H4sIAJz/BkQAA+xb63fTSLKfr9fn8D/0iDBOwJL8SAJ4SM6EJEDOmASSsMBZ
73pkqW1r0St6xPEw/O/3V/2QZMeB2T2X2S/X4Njqrq6uV1dXVbeDxY0bh4kf
cCu/yX/4Lq82Xrvb2/TZebzTFp/t7Y5ob7d77V20oaHd2Xn8eHsHcJ1ur7vz
A2t/H3KWX0WWOyljP/DJt+B4mv0VBP21r47FXvvRy/fsJzbvdZ3EZ+5iOvcj
ljjuJ2fKs3uNe42O1WEHGZvzZhAwCILlM67hlPWkbO7nM2aGUWzKnhYLnU+c
ZUUK+JjNnGt+r8HwcoCEEFw7qR8XGQv9aDpnTuTdQQHbjAGeYowTiYFFVjiB
xOXxax7EScijHJPEQbbVIpCIZX6YBAvmptzJJb2en3I3j9MFO+zbgmd77EfE
HiHaYOEnQDAzWdt9ImeexEEQg7ZpC1zMnUUmpOFoirMZB2+bYyebsRgEu9ls
SzAWxTlzQ8/iN0oGRRTwLAPJgccEd3MfiDYXccEizj0SGGFWY1gcgZc58eXG
0cSfFiloIMwS27jwA49a3uYtlnHOxhDKfMtiByCH3zgQBcToQBHZLJ5HYEMS
18LInPn4D1JS/9rXYsX0LqQ9FZILBTwxBVtxfJDSUmOUkB1oOs+hoXgCdY+z
3M+LHORIXAa/SeI0Zx8+fNj7+PGjwUi1geNyAjcynvPomjoZdVrS3LrsMpbm
E/gTzriT+TyFZhcJ79c0FhdQuzmBxpjt6nafVAXioJ4WPaxoZw6pwo4c1xUK
gFLf+5EXzzPYGwz4sD/M4pADg6bfyYDcLhuBMsu54xH1NDqMIVa3CMdwD4AB
7GLqQZa8PkiwZf4fvwhn12IDf+zDKq7lY4cdQcNBDAKXDFavJjZJ41AyNsvz
pG/b8/ncmkaFFadTEDzJ57ATe8qh0Jtcf1qzPAy0gAM1oQm30LbgPa3p73Ly
Lju+yVPHzcXc9NazQvx2kaV2ELtOYGepa4tVL4f12KF0ImKtkHzJRQQ1vqS+
XW95bt1u2XpVcHZ4uNecum7dETXZIUyvOX30aKX1xeDg5cVe0zzrCpD6o2ny
yBkH3AQtuQ90pudnsmEG+Xi1hijI8JSkfOLf7GnfUZoobLj+XXP3veyhhzWf
JVxO0PumNWTCHLQlOGKkFfHc1kKXTWbb2m1b26Wuq55dyMnctdqmNITx793l
Xj83YRajbru9097p9upgRF9lMKTxiU9u6ium0hOmolXtlIyW5rFErm5XLubN
weUrZmBVls69v0Ftxl9hRoDsdc2UE1M5tfz7Fkb7q1nav7I3zc46CyR5bbM3
Tu7OaJcO48gmCY/gmwPLTRKx2lSH5JxatTxhUGtHwU/4U/RDpdtmp2N2dlin
1+8+7e9sW239Yo8Q4an1+QgCWzu9epFtmJ2u2WuzLhDt9re76xH98gszu7ut
XfYIfx/jUTYz9XHfn3h8wt6fnPbICNXk92lDcIPC48xwMnfk0h5izZLE0MMq
gGd+bM32q3ag8yPODg4Pjy8u2EhuGWuGzeUGIsbeEl4lWS05zXN71+x2Wftx
v9ft99pLPHfXCK9CVBdah7W3+912f6d9t9C2uyQ0/F0nNC0cP85yBEthXTZa
hkVEkk0QdOQTPVAJ5+j4xcG7weVocHD6Elt9NHp3sTya2TY7Pbs87otgBBYg
AoUk9+NIhiRRPGcZ4jKYvAgh4aeMiWkwac8WY6/iOaK8lGRLJr2zdrdYdQZf
c7w9a3ctDhklukQaQlMZ+pauxbLsVZe3xnF8e/p1CG95yf/W9rFtsbeXPVtH
RC9SxJLHnk8Skd0d9pLL3T1AXJ3l7PBvFwzKyRREyd2yC19xxRh0fnZ2yYx+
gqwKw/tOFEcLxHPZL+51ZmVxkbocUeeU027Ut9GYxnFuX+VYa6XDRisL4ilF
6dTwLOV5kUb7bDOKscFl2TxOva06sPn7U6wmZqbgciQcxaiHf8/PD04PXzHT
u8p77Co3e0zZL3HcVR5UG0i1h0qfTvsBqUZsXi0ZNovgHPBj7LJZgMBZbGt5
LGlRLS1E5i5PSJoxQv3QST/RuIBWFewJAXThkOCt0qkg+pbzWOXUuif0M7ey
QvsbgJjj00it/OxbwEkaT1M4vq/AXZEA1vZLiBfIH2gJL0pJMWccX/OWjNQp
Hh9j6cURbepKwsrRbt5OsFr1dGqrlg9ktGv6zOSsmdnD4XDz7//c+Mdwyx7a
w449bbJnFOGP8nj/Tlbk30skWjJ1gA5rui1zG2RqSMbgu2LXLVLKxbak8yCf
KFaLop4Sp8PDFoUF+PPmjXA3g5PTX6WrW7YnsJ+V3Bwe4s8eW4lBVB+SJepb
jkRUHya5q09MvKavTHEdZHTRNOCVmjbvUq1gGBKA+pwgi5mjkj2a4+3rg1+P
1USWZRnIXH2soLCAv4CeZWZJOe4dY2rEifGawucpzELmFcJ8Kt3IUEZmrMYv
/kRYCL/xMeEzZPX77BnMZd8QUpe4YNUJNiLktJRfu7EHY/QtbrUwXjg201ND
//hDjW4xqXTZXCbfohOkLKiggZQTeaEL/5VxSr+zMpF242Rh7rtJC1YSmPtp
iPWfu5Z0Mj3hZcvknltjJy/DM6ptxMjTN8cLkTiTrRj9PhOZNOL3SKWiofJ1
wjvDi2BhzbgrnArZoa7KVCusNDYgg8weCB1cvDk+fMD29mrubbOEYupTxpyC
QKkmL8Z0JHT43E8teOX4k5hUynd5vPHg7eXRyfmDIbmXIVaMR+uy/GJopexH
RbA8EkTyNI3TgKo+rLNKmH5hl2HEyp5IHMBEtY1q0C3GAyq4rEfA3Vls3d2l
2F/iWS5oJQ2zPjG6i8AT5RzJmMlgFSkP42v+lTmGEtdwLJUcsgWMSiYxVDgT
OQQEnCKLCLEmeJjEKexPgik6oGePp3dwMo3zmB2fn5+dr4imfNySxqlziPAT
whU3s0vDsIVzsMhqWyyMPX+yIGPTtT0iMSNzk0UnUZNStNQXxu2NUlRiiC0q
kJEZzZ3U09tmuR0Kax0JP1l73eEyFTA5zmXgdX5SAgtv+WeBD8/efFwGdhNm
Tuogr8/+drwMEl6vgBwdD0YvTgbHFUgaroAcvvp1hMUzOv5wcnF5QSDKWy1N
9StAlqdSxU2p0R2lUencZTBeZoSyccojnjoIy5W+ZRI+kgqnLJHwbmaFS7sY
OSumRsCx692CbD5jTbtJRiCqaxlPHIFVV9EkHviv5rC5tc41bSAin0xYRaPM
oqpnCdZ7uuvirTyyYvtMAPX7YH2EmSEGYzg0fi5TNPll/25om4CX6FiWgqRl
nWSedN0n3To1by9yUbMlubwhUeyVE8K3J0U+IgU9Ym+P/LTfL+W0uYU2GnOK
5bCe8j+LeZW/W3g73acu3ssypBc20We0ol8GBd809Op4DhszWoY5GBr4GBqs
/GZs0QCD3Snq/wyplXJRN95sDofNFsyqNo20613tqZaj4dDxpXnD6ShjRbph
5jPkux7sVVVg3uY6EqV6eq5MXEQ30luzy4Png+NLxIGJqGhjP0bE5xRBvmUh
aPSFkWN6fIk41QrIH4+562AdVPGgqBJj5gwb95VO6hCpCM9XVvJfl6FNGSnK
jFuJ9AgZzOWr8+ODo9HFuzdvzs4vKcKO5CEBQZvwU5JDtViIrKkPGOuWTa+V
ljbutZ3KYtodF+9Vi5F5GDPqu+BXbKEEr4H1nrRdvJcxf2aG5AihmFGyh4c2
+9K6A/2dYzrlmJ12z8W7PpeqT1hvX8deQUrY08tsAE1hfSaBn2+S7QFrli8C
sVXFAR0oCJF/4mmEEGXue1MOzXq+g0QVGqbanc/nImTIEjoEQX4r4geY3jX8
nywO3oQBaOCIxVl2FajDCn/sY9aFBMlhR0XkGWxrvWD/cw6+J+krNHc6290W
/vTc8ltdCxNZcdqk6BdUsofgUsnXqr3KWo5aKQJArVGL3fkaRhUh6+cjqVar
qJrvKI6auT74XDfrN+dbUda6ib8Po+vne/hdGJU++bHI/skj1UpF0g2fyAQF
HljQcSIzyZkjjj8dz5OuUpcomyqnRh8dCkgzta+cBJbsikrJaO5XYUwdZhJH
ue5cjSzWIZCub12PHLr92Nl+0tp+qmVaVlGfiYoXL6vI9S5Ved5fnb9OnJq4
3iSBd7ed3Z2vTkeyfsIOq/PuqrCQLUKq+LBNeWpLB8zyiFnjIXBMPMvZJIid
3JptVUQGSGcyWc5T4DIUrFf4ljq04p+W5kro317S2R1lKGWFQ5E6j5lId1WR
xZfbVx4npkzzqnN7deKKfTpPOVfeW0ZftzPnWlRGTeJonbb3zJnwABs38n9d
01NBqKpJ09n3MrYJlawNdVBjyENzLxaSjVW2rTgjPHOfEhoujbfHXo9Z4KRT
ntYrVTCqdYSrkr3I/+KJivspmy0z872VgpVLLMiqag2a0us9mWX3h3v2AwW7

Re: Bugzilla 2315

[Enrico Forestieri]

Georg Baum [EMAIL PROTECTED] writes:
 
 Lars Gullik Bjønnes wrote:
 
  Then someone have to test it promptly or this will not be in 1.4.0.
 
 OK, here is an updated patch for testing (nothing had changed, I only moved
 the ChangeLog entry). Any takers?

With this patch the behavior is as in 1.3.7, including that when selecting a
math inset and pasting it outside of LyX, the delimiters are still left out.

Given that, I don't know why this patch is needed...

-- 
Enrico

Re: Bugzilla 2315

[Georg Baum]

Lars Gullik Bjønnes wrote:

 Then someone have to test it promptly or this will not be in 1.4.0.

Actually I think that John set the 1.4.0 target because at that time we
thought that math-insert was broken in general. Fortunately thsi has now
been resolved.
For me it is not too important to have this in 1.4.0. Maybe we should create
a fix that does not completely revert to 1.3 behaviour (always require
delimters), but makes it possible to convert with or without delimiters.


Georg

Re: Bugzilla 2315

[Juergen Spitzmueller]

Enrico Forestieri wrote:
 With this patch the behavior is as in 1.3.7, including that when selecting
 a math inset and pasting it outside of LyX, the delimiters are still left
 out.

 Given that, I don't know why this patch is needed...

try this:
1. write \text{test} in text mode
2. select it
3. hit C-M

you get an ampty text inset. The patch fixes that.

The bug is not about copy and paste, but about text-math conversion.

Jürgen

Re: Bugzilla 2315

[Lars Gullik Bjønnes]

Georg Baum [EMAIL PROTECTED] writes:

| Lars Gullik Bjønnes wrote:
| 
|  Then someone have to test it promptly or this will not be in 1.4.0.
| 
| Actually I think that John set the 1.4.0 target because at that time we
| thought that math-insert was broken in general. Fortunately thsi has now
| been resolved.
| For me it is not too important to have this in 1.4.0. Maybe we should create
| a fix that does not completely revert to 1.3 behaviour (always require
| delimters), but makes it possible to convert with or without delimiters.

Ok.

To make thing trot along I'll move this (2315) to 1.4.1.

Please do not commit the 2315 patch.

-- 
Lgb

Re: Bugzilla 2315

[Georg Baum]

Juergen Spitzmueller wrote:

 Enrico Forestieri wrote:
 With this patch the behavior is as in 1.3.7, including that when
 selecting a math inset and pasting it outside of LyX, the delimiters are
 still left out.

Enrico, could you file the paste outside of LyX bug in bugzilla, please (or
si it alreday there?)

 Given that, I don't know why this patch is needed...
 
 try this:
 1. write \text{test} in text mode
 2. select it
 3. hit C-M
 
 you get an ampty text inset. The patch fixes that.

OK, forget my previous post about being this no 1.4.0 stuff. I was confused.
Here is a better patch (only two code lines were changed), that does allow
all these cases:

\text{test}
$\text{test}$
\[\text{test}\]
\begin{align}\text{test}\end{align}

etc. Of course \text{test} can be replaced by anything that can be in a math
formula.

Jürgen, Enrico, it would be nice if you could test this one again, so that
it can go in 1.4.0. For me it does work.

 The bug is not about copy and paste, but about text-math conversion.

Yes.


GeorgIndex: src/ChangeLog
===
--- src/ChangeLog	(Revision 13280)
+++ src/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,7 @@
+2006-02-26  Georg Baum  [EMAIL PROTECTED]
+
+	* text3.C (mathDispatch): fix math inset creation from string (bug 2315)
+
 2006-02-28  Martin Vermeer  [EMAIL PROTECTED]
 
 	* cursor.C (niceInsert): fix (properly) insertion of
Index: src/text3.C
===
--- src/text3.C	(Revision 13280)
+++ src/text3.C	(Arbeitskopie)
@@ -158,16 +158,21 @@ namespace {
 			// create a macro if we see \\newcommand
 			// somewhere, and an ordinary formula
 			// otherwise
+			istringstream is(sel);
 			if (sel.find(\\newcommand) == string::npos
 			 sel.find(\\def) == string::npos)
 			{
-cur.insert(new MathHullInset(simple));
-cur.dispatch(FuncRequest(LFUN_RIGHT));
-cur.dispatch(FuncRequest(LFUN_INSERT_MATH, sel));
-			} else {
-istringstream is(sel);
+MathHullInset * formula = new MathHullInset;
+LyXLex lex(0, 0);
+lex.setStream(is);
+formula-read(cur.buffer(), lex);
+if (formula-getType() == none)
+	// Don't create pseudo formulas if
+	// delimiters are left out
+	formula-mutate(simple);
+cur.insert(formula);
+			} else
 cur.insert(new MathMacroTemplate(is));
-			}
 		}
 		cur.message(N_(Math editor mode));
 	}

Re: Bugzilla 2315

[Enrico Forestieri]

Juergen Spitzmueller [EMAIL PROTECTED] writes:
 
 try this:
 1. write \text{test} in text mode
 2. select it
 3. hit C-M
 
 you get an ampty text inset. The patch fixes that.

Yes, I was missing that. Then I would say that the patch works, even if
it is a small nuisance that now you have to include some delimiter in
the selection before hitting C-M.

-- 
Enrico

Re: Bugzilla 2315

[Juergen Spitzmueller]

Georg Baum wrote:
 Jürgen, Enrico, it would be nice if you could test this one again, so that
 it can go in 1.4.0. For me it does work.

I'll test intensely now. Lars, I agree with Georg that this should be applied, 
given that it proves good (and it's not too late yet).

Jürgen

Re: Bugzilla 2315

[Georg Baum]

Lars Gullik Bjønnes wrote:

 To make thing trot along I'll move this (2315) to 1.4.1.
 
 Please do not commit the 2315 patch.

OK. Since Jürgen has pointed out that there was a bigger problem than I
thought (sorry again for the confusion), I would really like an entry in
the release notes.

May I commit the attached instead?


GeorgIndex: RELEASE-NOTES
===
--- RELEASE-NOTES	(Revision 13280)
+++ RELEASE-NOTES	(Arbeitskopie)
@@ -45,3 +45,6 @@ they have not yet been applied because o
   http://bugzilla.lyx.org/show_bug.cgi?id=2284
   http://bugzilla.lyx.org/show_bug.cgi?id=2242
 
+- Text - math conversion does sometimes not work
+  http://bugzilla.lyx.org/show_bug.cgi?id=2315
+

Re: Bugzilla 2315

[Enrico Forestieri]

Georg Baum [EMAIL PROTECTED] writes:
 
 Enrico, could you file the paste outside of LyX bug in bugzilla, please (or
 si it alreday there?)

I'll do that.

 Here is a better patch (only two code lines were changed), that does allow
 all these cases:
 
 \text{test}
 $\text{test}$
 \[\text{test}\]
 \begin{align}\text{test}\end{align}

I think that these particular examples already worked with the previous
patch.

 etc. Of course \text{test} can be replaced by anything that can be in a math
 formula.
 
 Jürgen, Enrico, it would be nice if you could test this one again, so that
 it can go in 1.4.0. For me it does work.

Ok.

-- 
Enrico

Re: Bugzilla 2315

[Lars Gullik Bjønnes]

Georg Baum [EMAIL PROTECTED] writes:

| Juergen Spitzmueller wrote:
| 
|  Enrico Forestieri wrote:
|  With this patch the behavior is as in 1.3.7, including that when
|  selecting a math inset and pasting it outside of LyX, the delimiters are
|  still left out.
| 
| Enrico, could you file the paste outside of LyX bug in bugzilla, please (or
| si it alreday there?)
| 
|  Given that, I don't know why this patch is needed...
|  
|  try this:
|  1. write \text{test} in text mode
|  2. select it
|  3. hit C-M
|  
|  you get an ampty text inset. The patch fixes that.
| 
| OK, forget my previous post about being this no 1.4.0 stuff. I was confused.
| Here is a better patch (only two code lines were changed), that does allow
| all these cases:
| 
| \text{test}
| $\text{test}$
| \[\text{test}\]
| \begin{align}\text{test}\end{align}
| 
| etc. Of course \text{test} can be replaced by anything that can be in a math
| formula.
| 
| Jürgen, Enrico, it would be nice if you could test this one again, so that
| it can go in 1.4.0. For me it does work.
| 
|  The bug is not about copy and paste, but about text-math conversion.

Ok count me confused.

Please all, make up your mind about this bug. Required for 1.4.0 or
not.

-- 
Lgb

Re: Bugzilla 2315

[Lars Gullik Bjønnes]

Juergen Spitzmueller [EMAIL PROTECTED] writes:

| Georg Baum wrote:
|  Jürgen, Enrico, it would be nice if you could test this one again, so that
|  it can go in 1.4.0. For me it does work.
| 
| I'll test intensely now. Lars, I agree with Georg that this should be 
applied, 
| given that it proves good (and it's not too late yet).

I'll hold off pre6 some hours yet.

-- 
Lgb

Re: Bugzilla 2315

[Juergen Spitzmueller]

Lars Gullik Bjønnes wrote:
 Please all, make up your mind about this bug. Required for 1.4.0 or
 not.

I did already (required for 1.4.0)

Just testing ...

Jürgen

Re: Bugzilla 2315

[Enrico Forestieri]

Georg Baum [EMAIL PROTECTED] writes:
 
 Jürgen, Enrico, it would be nice if you could test this one again, so that
 it can go in 1.4.0. For me it does work.

The new patch seems to work. However, if the selection does not include
any delimiter I get some messages on the terminal. For example, selecting
$\alpha$ and hitting C-M is fine, but simply selecting \alpha and then C-M
gives the following message:

unusual contents found: [symbol alpha]

even if the conversion does work. I tried several normal and AMS math
environments and everything seems to be fine (with warnings when a
delimiter is missing).

Then I tried something unusual, i.e., I selected $a$ foo $b$ (double
quotes excluded) and hit C-M. Everything seemed to be translated in math
mode but exporting to latex revealed that I had got

$$a$ foo $b$$

which is clearly incorrect. The message on the console in this case was:

unusual contents found: [formula simple [grid [row [cell [char a mathalpha]
[char   mathalpha][char f mathalpha][char o mathalpha][char o mathalpha][char   
mathalpha][formula simple [grid [row [cell [char b mathalpha]

To be honest I don't know if this can be regarded as a bug, as I have
no opinions on what should have happened. Anyway, the generated latex
is incorrect.

-- 
Enrico

Re: Bugzilla 2315

[Jose' Matos]

On Thursday 02 March 2006 17:37, Enrico Forestieri wrote:
 To be honest I don't know if this can be regarded as a bug, as I have
 no opinions on what should have happened. Anyway, the generated latex
 is incorrect.

  This is not a regression either because this happened for 1.3.x as well, 
IIRC. At least for now that is the major concern. :-)

 --
 Enrico

-- 
José Abílio

Re: Bugzilla 2315

[Juergen Spitzmueller]

Jose' Matos wrote:
  To be honest I don't know if this can be regarded as a bug, as I have
  no opinions on what should have happened. Anyway, the generated latex
  is incorrect.

   This is not a regression either because this happened for 1.3.x as well,
 IIRC. At least for now that is the major concern. :-)

No, in 1.3, it has been correctly converted to
$a$ foo $b$
because everything without $-delimters has been regarded as math-TEXT.

But I guess this is the price to pay for the freedom of using delimiters or 
not. However, it seems to me that at least
$a$ $foo$ $b$
would be more sensible.

However, I agree that we could live with this minor glitch in 1.4.0

Jürgen

Re: Bugzilla 2315

[Enrico Forestieri]

Georg Baum [EMAIL PROTECTED] writes:
 
 Juergen Spitzmueller wrote:
 
  Enrico Forestieri wrote:
  With this patch the behavior is as in 1.3.7, including that when
  selecting a math inset and pasting it outside of LyX, the delimiters are
  still left out.
 
 Enrico, could you file the paste outside of LyX bug in bugzilla, please (or
 si it alreday there?)

It is now bug 2342.

http://bugzilla.lyx.org/show_bug.cgi?id=2342

-- 
Enrico

Re: LyX/Win 1.4.0

[Angus Leeming]

Angus Leeming wrote:

Grab it from:
http://wiki.lyx.org/uploads/Windows/LyX140pre/lyx-1.4.0pre_win32_setup_v1.exe 

I anticipate that the installer will have the same bugs as the 1.3.x 
version since the installer code is little different to the previous 
version. (The one real change being that I've removed all tests for Perl 
in the installer.)


I found some time to investigate the problems with the insertion of the 
path_prefix entry. As a result, I've squashed the numerous bugs in 
lyx_configure.C. At the very least, the new version should give us an 
informative error message, albeit one that's output to console for now.


The new version is at
http://wiki.lyx.org/uploads/Windows/LyX140pre/lyx-1.4.0pre_win32_setup_v2.exe

Lars, I'm going to reboot this machine into linux right now so that I can 
apply and commit the changes to both head and to the 1.4 branch. Jean-Marc, 
if you're OK, I'll also commit a part of this patch to the 1.3 branch; 
lyx_configure.C is compiled into a .dll and it would be nice to use the 
same one for both the 1.3 and 1.4 installers.


Patch attached for info.

Angus



packaging.diff.bz2
Description: Binary data

Re: Bugzilla 2315

[Juergen Spitzmueller]

Georg Baum wrote:
 Jürgen, Enrico, it would be nice if you could test this one again, so that
 it can go in 1.4.0. For me it does work.

It works for me, except for the glitch Enrico reported, and the following 
issue of which I'm not sure if it is related:

1. Insert formula
2. type foo
3. mark foo
4. hit C-M

you get an empty math-text inset. 1.3 copied the selected content inside the 
inset. Same problem vice versa (C-m with marked text inside math-text).

However, this issue happens with or without the patch, so the patch basically 
works for what it is advertised.

Jürgen

Re: Bugzilla 2315

[Georg Baum]

Juergen Spitzmueller wrote:

 Georg Baum wrote:
 Jürgen, Enrico, it would be nice if you could test this one again, so
 that it can go in 1.4.0. For me it does work.
 
 It works for me, except for the glitch Enrico reported, and the following
 issue of which I'm not sure if it is related:
 
 1. Insert formula
 2. type foo
 3. mark foo
 4. hit C-M
 
 you get an empty math-text inset. 1.3 copied the selected content inside
 the inset. Same problem vice versa (C-m with marked text inside
 math-text).
 
 However, this issue happens with or without the patch, so the patch
 basically works for what it is advertised.

So it is not related to the patch.

Enrico and Jürgen, thanks for your testing.

Summary:

The patch fixes the C-M text-math conversion for all tested cases of
_valid_ math formulas, with or without delimiters. It has the following
drawbacks:
1) It creates a warning on the console if a formula without delimiters is
converted.
2) It produces invalid results for things that are not really _one_ formula,
e.g. the mentioned $a$ foo $b$.

1) is not the case currently in 1.4, but is IMHO a good trade-off wrt the
currently not working \text{test} conversion.
2) is a regression wrt. 1.3, but IMHO not important because this kind of
pseudo formulas has never been officially supported.

This is IMHO enough data now to make a decision. I'd say that the patch can
go in, because the advantages clearly outweigh the disadvantages.

Lars, what is your opinion?


Georg

[PATCHES 13x, 14x, head] The updated Windows installer stuff

[Angus Leeming]

Attached are the patches that I'd like to apply to the repository. The
patches for the 1.4.x branch and for head are identical. The patch for the
1.3.x branch is simply the cleaned up lyx_configure.C file backported from
1.4.x/head. It allows the 1.3.x installer to use the same
lyx_configure.dll and (more importantly) fixes the broken setting of the
path_prefix variable in lyxrc.defaults.

I'll apply the patches to 14x and to head now. I'll wait on JMarc's say so
for the 13x patch.

-- 
Angus

win_packaging_13x.diff.bz2
Description: BZip2 compressed data


win_packaging_14x.diff.bz2
Description: BZip2 compressed data


win_packaging_head.diff.bz2
Description: BZip2 compressed data

Re: [PATCHES 13x, 14x, head] The updated Windows installer stuff

[Angus Leeming]

Angus Leeming wrote:

 Attached are the patches that I'd like to apply to the repository. The
 patches for the 1.4.x branch and for head are identical. The patch for
 the 1.3.x branch is simply the cleaned up lyx_configure.C file backported
 from 1.4.x/head. It allows the 1.3.x installer to use the same
 lyx_configure.dll and (more importantly) fixes the broken setting of the
 path_prefix variable in lyxrc.defaults.

 I'll apply the patches to 14x and to head now. I'll wait on JMarc's say
 so for the 13x patch.

Ok, Lars, I've committed. pre6 is now ready to roll from my end.

-- 
Angus

Re: Bugzilla 2315

[Lars Gullik Bjønnes]

Georg Baum [EMAIL PROTECTED] writes:

| Juergen Spitzmueller wrote:
| 
|  Georg Baum wrote:
|  Jürgen, Enrico, it would be nice if you could test this one again, so
|  that it can go in 1.4.0. For me it does work.
|  
|  It works for me, except for the glitch Enrico reported, and the following
|  issue of which I'm not sure if it is related:
|  
|  1. Insert formula
|  2. type foo
|  3. mark foo
|  4. hit C-M
|  
|  you get an empty math-text inset. 1.3 copied the selected content inside
|  the inset. Same problem vice versa (C-m with marked text inside
|  math-text).
|  
|  However, this issue happens with or without the patch, so the patch
|  basically works for what it is advertised.
| 
| So it is not related to the patch.
| 
| Enrico and Jürgen, thanks for your testing.
| 
| Summary:
| 
| The patch fixes the C-M text-math conversion for all tested cases of
| _valid_ math formulas, with or without delimiters. It has the following
| drawbacks:
| 1) It creates a warning on the console if a formula without delimiters is
| converted.
| 2) It produces invalid results for things that are not really _one_ formula,
| e.g. the mentioned $a$ foo $b$.
| 
| 1) is not the case currently in 1.4, but is IMHO a good trade-off wrt the
| currently not working \text{test} conversion.
| 2) is a regression wrt. 1.3, but IMHO not important because this kind of
| pseudo formulas has never been officially supported.
| 
| This is IMHO enough data now to make a decision. I'd say that the patch can
| go in, because the advantages clearly outweigh the disadvantages.
| 
| Lars, what is your opinion?

Put it in please.

Maintrunk first and then merge the revision to the branch.

-- 
Lgb

Re: Bugzilla 2315

[Georg Baum]

Am Donnerstag, 2. März 2006 20:22 schrieb Lars Gullik Bjønnes:
 Put it in please.
 
 Maintrunk first and then merge the revision to the branch.

Done. I had to look up the options of svn merge because I don't use it 
that often, but it looks like it has worked.


Georg

Re: Bugzilla 2315

[Angus Leeming]

Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
 Put it in please.
 Maintrunk first and then merge the revision to the branch.

Now I know I should go and read the subversion docs, but is this merge to the
branch actually:

cd head
svn diff  head.diff
svn commit
cd ../14x
patch -p0  ../head/head.diff
svn commit

(which is what I've just done with the windows installer stuff)

Or is it some subversion magic?

Angus

Re: Bugzilla 2315

[Georg Baum]

Am Donnerstag, 2. März 2006 21:12 schrieb Angus Leeming:
 Now I know I should go and read the subversion docs, but is this merge 
to the
 branch actually:
 
 cd head
 svn diff  head.diff
 svn commit
 cd ../14x
 patch -p0  ../head/head.diff
 svn commit
 
 (which is what I've just done with the windows installer stuff)
 
 Or is it some subversion magic?

I did:

svn merge -r 13285:13286  svn+ssh://[EMAIL PROTECTED]/lyx/lyx-devel/trunk
svn commit

I do not know the advantages over the diff method (that I have used until 
now), because I did not yet merge that often with svn.


Georg

Re: [PATCHES 13x, 14x, head] The updated Windows installer stuff

[Jean-Marc Lasgouttes]

 Angus == Angus Leeming [EMAIL PROTECTED] writes:

Angus I'll apply the patches to 14x and to head now. I'll wait on
Angus JMarc's say so for the 13x patch.

You can apply the 13x patch. I won't use for a 1.3.8 anyway, but it is
useful to keep things in one place.

Will you release a new 1.3.7 installer?

JMarc

Re: DVI search.

[João Luis Meloni Assirati]

Em Qui 02 Mar 2006 05:19, Lars Gullik Bjønnes escreveu:
 João Luis Meloni Assirati [EMAIL PROTECTED] writes:
 | Index: src/LaTeX.C
 | ===
 | --- src/LaTeX.C (revision 13280)
 | +++ src/LaTeX.C (working copy)
 | @@ -383,7 +383,8 @@
 |
 |  int LaTeX::startscript()
 |  {
 | -   string tmp = cmd + ' ' + QuoteName(file) ++ os::nulldev();
 | +   string tmp = cmd + (runparams.srcspecials?(' ' +
 | lyxrc.source_specials_switch):) + +   ' ' + QuoteName(file) + 
+
 | os::nulldev();

 ostringstream perhaps? At least use temps/foramtting to make the line
 look nicer.

Changed to:

string tmp = cmd;
if (runparams.srcspecials)
tmp += ' ' + lyxrc.source_specials_switch;
tmp += ' ' + QuoteName(file) ++ os::nulldev();


 | Index: src/converter.h
 | ===
 | --- src/converter.h (revision 13280)
 | +++ src/converter.h (working copy)
 | @@ -137,7 +138,7 @@
 |  std::string const  filename);
 | ///
 | bool runLaTeX(Buffer const  buffer, std::string const  command,
 | - OutputParams const );
 | + std::string const  name, OutputParams const );

 Why not add the name to the OutputParams?
 Is 'name' a nice name for this parameter?

I moved it to OutputParams under the name latexfile. This allows for some 
cleanups, as for example

LaTeX::LaTeX(string const  latex, OutputParams const  rp,
 string const  f, string const  p)
: cmd(latex), file(f), path(p), runparams(rp)

(file can be taken now from rp), but I will not touch this.


 | ///
 | ConverterList converterlist_;
 | ///
 | Index: src/lyxrc.C
 | ===
 | --- src/lyxrc.C (revision 13280)
 | +++ src/lyxrc.C (working copy)
 | @@ -280,6 +282,8 @@
 | preview = PREVIEW_OFF;
 | preview_hashed_labels  = false;
 | preview_scale_factor = 0.9;
 | +   source_specials_switch = ;
 | +   dvi_fwsearch_switch = ;

 Not needed.

OK, removed. Note that we have also

roman_font_name = ;
sans_font_name = ;
typewriter_font_name = ;

in LyXRC::setDefaults().


 | Index: src/texrow.C
 | ===
 | --- src/texrow.C(revision 13280)
 | +++ src/texrow.C(working copy)
 | @@ -78,6 +78,39 @@
 |  }
 |
 |
 | +int TexRow::getRowFromId(int id, int pos) const
 | +{
 | +   RowList::const_iterator cit = rowlist.begin();
 | +   int diff_id = abs(cit-id() - id);
 | +   int best_id = cit-id();
 | +   int diff_pos = abs(cit-pos() - pos);
 | +   int best_row = cit-rownumber();
 | +   while (cit != rowlist.end()) {
 | +   ++cit;

 This looks wrong. If cit == rowlist.end() - 1, then ++cit will bring
 it to rowlist.end() and all operations on it will be bogus.

 Please also change to use a for loop and don't reevaluate
 rowlist.end() on each iteration.

Thanks on this. I think it is better now:

int TexRow::getRowFromId(int id, int pos) const
{
RowList::const_iterator cit = rowlist.begin();
RowList::const_iterator rowlist_end = rowlist.end();
[...]
for (++cit; cit != rowlist_end; ++cit) {
[...]
}
return best_row;
}


Attached is the updated patch.

Thanks,
João.
Index: src/BufferView.h
===
--- src/BufferView.h	(revision 13280)
+++ src/BufferView.h	(working copy)
@@ -179,6 +179,8 @@
 	int offset_ref() const;
 	/// access to anchor
 	lyx::pit_type anchor_ref() const;
+	/// access to the texrow corresponding to the beginning of the view
+	int texrow_ref() const;
 
 	/// access to full cursor
 	LCursor  cursor();
Index: src/BufferView.C
===
--- src/BufferView.C	(revision 13280)
+++ src/BufferView.C	(working copy)
@@ -387,6 +387,13 @@
 }
 
 
+int BufferView::texrow_ref() const 
+{
+	return buffer()-texrow().getRowFromId(
+		buffer()-paragraphs()[anchor_ref()].id(), offset_ref());
+}
+
+
 int BufferView::offset_ref() const
 {
 	return pimpl_-offset_ref_;
Index: src/LaTeX.C
===
--- src/LaTeX.C	(revision 13280)
+++ src/LaTeX.C	(working copy)
@@ -383,7 +383,10 @@
 
 int LaTeX::startscript()
 {
-	string tmp = cmd + ' ' + QuoteName(file) ++ os::nulldev();
+	string tmp = cmd;
+	if (runparams.srcspecials)
+		tmp += ' ' + lyxrc.source_specials_switch;
+	tmp += ' ' + QuoteName(file) ++ os::nulldev();
 	Systemcall one;
 	return one.startscript(Systemcall::Wait, tmp);
 }
Index: src/buffer.C
===
--- src/buffer.C	(revision 13280)
+++ src/buffer.C	(working copy)
@@ -1280,7 +1280,7 @@
 
 	switch (func.action) {
 		case LFUN_EXPORT: {
-			bool const tmp = 

Re: DVI search.

[João Luis Meloni Assirati]

Em Qui 02 Mar 2006 05:22, Lars Gullik Bjønnes escreveu:
 João Luis Meloni Assirati [EMAIL PROTECTED] writes:
 | Index: src/texrow.h
 | ===
 | --- src/texrow.h(revision 13280)
 | +++ src/texrow.h(working copy)
 | @@ -46,6 +46,9 @@
 |  */
 | bool getIdFromRow(int row, int  id, int  pos) const;
 |
 | +   /// getRowFromId - find the closest row for a given (id, pos) pair
 | +   int TexRow::getRowFromId(int id, int pos) const;
 | +

 This 'TexRow::' is actually a syntax error and will give warning/error
 with gcc 4.1.

I don't get it. What is the problem?

 Note also that I plan to get rid of TexRow completely later, infavour
 of unique id's on paragraphs and offsets into the paragraph. Then we
 can have dvi files that can contain sourcespecials and we can send
 them around and expect the reverse search to work.

Latex reports errors in terms of rows in the latex file. How then do you plan 
to map rows into ids a and offsets in order to locate those errors?

João.

Re: DVI search.

[Jose' Matos]

On Thursday 02 March 2006 21:32, João Luis Meloni Assirati wrote:

Olá João, :-)
 (Oi seria melhor ? ;-)

  | Index: src/texrow.h
  | ===
  | --- src/texrow.h  (revision 13280)
  | +++ src/texrow.h  (working copy)
  | @@ -46,6 +46,9 @@
  |*/
  |   bool getIdFromRow(int row, int  id, int  pos) const;
  |
  | + /// getRowFromId - find the closest row for a given (id, pos) pair
  | + int TexRow::getRowFromId(int id, int pos) const;
  | +
 
  This 'TexRow::' is actually a syntax error and will give warning/error
  with gcc 4.1.

 I don't get it. What is the problem?

class TexRow {
...
int TexRow::getRowFromId(int id, int pos) const;
...
}

The use of TexRow classifier inside the class is wrong, since the function is 
declared there. The right syntax is:

class TexRow {
...
int getRowFromId(int id, int pos) const;
...
}

 João.

-- 
José Abílio

Re: Bugzilla 2315

[Martin Vermeer]

On Thu, Mar 02, 2006 at 08:04:33PM +0100, Georg Baum wrote:
 Juergen Spitzmueller wrote:
 
  Georg Baum wrote:

...

 2) It produces invalid results for things that are not really _one_ formula,
 e.g. the mentioned $a$ foo $b$.

Actually a simple fix that comes to my mind is to simply strip out all
internal dollar signs before trying to parse the string.

Then, in an earlier patch of mine posted on the list, the MathFontInset
output routine would again add the dollar signs around any equations
found embedded in \textrm-like fontinsets, which is the only place they
are required.

- Martin



pgpXALnRBT89s.pgp
Description: PGP signature

Re: DVI search.

[João Luis Meloni Assirati]

Em Qui 02 Mar 2006 07:31, Angus Leeming escreveu:
 João Luis Meloni Assirati [EMAIL PROTECTED] writes:
   * if LyX were able to talk to xdvi through the lyxclient interface,
   then we wouldn't have to keep creating a new xdvi process in client
   mode each time I click in the LyX window which is what happens now.
 
  No. We don't create a new xdvi process each time we click in the lyx
  window. View - DVI remains the only way to start a new xdvi process.
  Forward search means that this new xdvi will start at the right page.
  What occours now is that xdvi is called with the option

 Sorry to be pedantic, but from LyX's point of view that's creating a new
 xdvi isn't it? I.e., your xdvi is called is my 'system(xdvi option1
 option2);'. Or, eventually, when system() is consigned to the waste bin of
 history we'll be using fork() and 'execvp(xdvi, [xdvi, option1,
 option2, 0]);'

 What xdvi itself does with this is a separate matter. (Whether a whole new
 and fully-functional instance of xdvi is created or whether the newly
 created process just posts the new info to an existing, running xdvi client
 for it to update its data.)

You are right.

I was trying to say that forward search is not as interactive as inverse 
search. In inverse search, you can scroll xdvi up or down and control-click 
in the xdvi window to make lyx search the corresponding text. In forward 
search, you have to scroll to the desired point in the lyx window then call  
View - DVI. There is no interface like control-click in the lyx window to 
get xdvi to jump to the desired location. That is a cool idea, though.


 Anyway, the whole discussion is just for my academic interest, so don't let
 my pedantry bother you :)

It won't!

  There is also a high level tool to communicate with xdvi, which is xdvi
  itself (i.e., there is no xdviclient; instead, xdvi itself can work in
  client mode). It communicates with another running xdvi not through a
  socket like we do, but through something called X properties, a native
  xwindow message passing protocol (the same way emacsclient and 'mozilla
  -remote' do
  (http://www.mozilla.org/unix/remote.html)).

 Interesting. Thanks. FWIW it appears that Windows apps tend to use a
 similar technique to prevent multiple instances of an app from running
 simultaneously.

The network transparency of Xwindow system sometimes makes this feature 
confusing. For example, if you want to have two mozillas runing in the same 
display, one runing locally and the other runing on another computer, you 
have to avoid this mechanism. I've been through this.

  Beautiful. You are a coruja (owl) like we say in Brazil, meaning a very
  proud and loving dad (applies to a mom, too)  :).

 Less loving this morning as the wee bugger kept us up all night for no good
 reason. Pushing at boundaries already :)

I wish you a better night today :).


 Angus

João.

Re: [PATCHES 13x, 14x, head] The updated Windows installer stuff

[Angus Leeming]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
 Angus I'll apply the patches to 14x and to head now. I'll wait on
 Angus JMarc's say so for the 13x patch.

 You can apply the 13x patch.

Ok, will do.

 I won't use for a 1.3.8 anyway,

Sorry, but that's bad grammar and I don't understand it. Are you trying to say
I don't anticipate creating a 1.3.8 release? If so, I appreciate that, but if
the worst happens and a 1.3.8 release is needed, then it'd be nice if it 'just
worked'.

 but it is useful to keep things in one place.
 Will you release a new 1.3.7 installer?

Dunno yet. It would be nice if someone knowledgable would tell me how to play
with the iconv-enabled gettext thingie...

I'd also have to play with the Aspell 0.6 stuff (download the dictionaries to
the expected place) unless someone else beats me to it and can confirm that the
spell checker is working.

Angus

Re: LyX/Win 1.4.0

[Angus Leeming]

Stephen Harris wrote:

Angus wrote:

I anticipate that the installer will have the same bugs as the 1.3.x 
version since the installer code is little different to the previous 
version. (The one real change being that I've removed all tests for Perl 
in the installer.)

--

The install completed quickly. The File/Import started with just the two 
options for lines. I ran sh configure in C:\Lyx140\Resouces as usual for 
me.. Reconfigure, and regained Latex as an import option.


I got an error message during the install: Failed attempting to set
path_prefix in the configure script.


Hi, Stephen.

This problem with the path_prefix stuff should now be fixed. Perhaps you'd 
like to test it out?


http://wiki.lyx.org/uploads/Windows/LyX137/lyx-1.3.7_win32_setup_v4.exe
http://wiki.lyx.org/uploads/Windows/LyX140pre/lyx-1.4.0pre_win32_setup_v2.exe

I'm still mulling over what to do with aspell. If we go for aspell 0.6 then 
it looks like I'll have to supply the dictionaries too. Would make Kevin 
Atkinson happy :)


Angus

Re: DVI search.

[João Luis Meloni Assirati]

Em Qui 02 Mar 2006 18:40, Jose' Matos escreveu:

Oi José!

 On Thursday 02 March 2006 21:32, João Luis Meloni Assirati wrote:

 Olá João, :-)
  (Oi seria melhor ? ;-)

Está bem das duas maneiras. Gosto do modo português de falar, também :)
(Lars, keep reading, please :)

 
  I don't get it. What is the problem?

 class TexRow {
 ...
 int TexRow::getRowFromId(int id, int pos) const;
 ...
 }

 The use of TexRow classifier inside the class is wrong, since the function
 is declared there. The right syntax is:

 class TexRow {
 ...
 int getRowFromId(int id, int pos) const;
 ...
 }

Sorry, guys. I hadn't reallized that Lars post  was about the .h file. I 
understand now, it was a stupid error. Attached is the updated patch.

Thanks,
João.
Index: src/BufferView.h
===
--- src/BufferView.h	(revision 13280)
+++ src/BufferView.h	(working copy)
@@ -179,6 +179,8 @@
 	int offset_ref() const;
 	/// access to anchor
 	lyx::pit_type anchor_ref() const;
+	/// access to the texrow corresponding to the beginning of the view
+	int texrow_ref() const;
 
 	/// access to full cursor
 	LCursor  cursor();
Index: src/BufferView.C
===
--- src/BufferView.C	(revision 13280)
+++ src/BufferView.C	(working copy)
@@ -387,6 +387,13 @@
 }
 
 
+int BufferView::texrow_ref() const 
+{
+	return buffer()-texrow().getRowFromId(
+		buffer()-paragraphs()[anchor_ref()].id(), offset_ref());
+}
+
+
 int BufferView::offset_ref() const
 {
 	return pimpl_-offset_ref_;
Index: src/LaTeX.C
===
--- src/LaTeX.C	(revision 13280)
+++ src/LaTeX.C	(working copy)
@@ -383,7 +383,10 @@
 
 int LaTeX::startscript()
 {
-	string tmp = cmd + ' ' + QuoteName(file) ++ os::nulldev();
+	string tmp = cmd;
+	if (runparams.srcspecials)
+		tmp += ' ' + lyxrc.source_specials_switch;
+	tmp += ' ' + QuoteName(file) ++ os::nulldev();
 	Systemcall one;
 	return one.startscript(Systemcall::Wait, tmp);
 }
Index: src/buffer.C
===
--- src/buffer.C	(revision 13280)
+++ src/buffer.C	(working copy)
@@ -1280,7 +1280,7 @@
 
 	switch (func.action) {
 		case LFUN_EXPORT: {
-			bool const tmp = Exporter::Export(this, func.argument, false);
+			bool const tmp = Exporter::Export(this, func.argument, false, false);
 			if (result)
 *result = tmp;
 			break;
Index: src/converter.h
===
--- src/converter.h	(revision 13280)
+++ src/converter.h	(working copy)
@@ -107,12 +107,13 @@
 	bool convert(Buffer const * buffer,
 		 std::string const  from_file, std::string const  to_file_base,
 		 std::string const  from_format, std::string const  to_format,
- std::string  to_file, bool try_default = false);
+		 std::string  to_file, bool try_default = false,
+		 bool for_preview = false);
 	///
 	bool convert(Buffer const * buffer,
 		 std::string const  from_file, std::string const  to_file_base,
 		 std::string const  from_format, std::string const  to_format,
- bool try_default = false);
+ bool try_default = false, bool for_preview = false);
 	///
 	void update(Formats const  formats);
 	///
Index: src/converter.C
===
--- src/converter.C	(revision 13280)
+++ src/converter.C	(working copy)
@@ -281,7 +281,8 @@
 bool Converters::convert(Buffer const * buffer,
 			 string const  from_file, string const  to_file_base,
 			 string const  from_format, string const  to_format,
-			 string  to_file, bool try_default)
+			 string  to_file, bool try_default,
+			 bool for_preview)
 {
 	string const to_ext = formats.extension(to_format);
 	to_file = ChangeExtension(to_file_base, to_ext);
@@ -323,6 +324,8 @@
 	}
 	OutputParams runparams;
 	runparams.flavor = getFlavor(edgepath);
+	runparams.srcspecials = (for_preview  to_format == dvi);
+	runparams.latexfile = from_file;
 	string path = OnlyPath(from_file);
 	Path p(path);
 
@@ -515,11 +518,11 @@
 bool Converters::convert(Buffer const * buffer,
 			 string const  from_file, string const  to_file_base,
 			 string const  from_format, string const  to_format,
- bool try_default)
+ bool try_default, bool for_preview)
 {
 	string to_file;
 	return convert(buffer, from_file, to_file_base, from_format, to_format,
-		   to_file, try_default);
+		   to_file, try_default, for_preview);
 }
 
 
@@ -576,7 +579,7 @@
 	runparams.document_language = buffer.params().language-babel();
 
 	// do the LaTeX run(s)
-	string const name = buffer.getLatexName();
+	string const name = runparams.latexfile;
 	LaTeX latex(command, runparams, name, buffer.filePath());
 	TeXErrors terr;
 	showMessage show(buffer);
Index: src/exporter.h

Re: LyX/Win 1.4.0

[Joost Verburg]

Angus Leeming wrote:
I'm still mulling over what to do with aspell. If we go for aspell 0.6 
then it looks like I'll have to supply the dictionaries too. Would make 
Kevin Atkinson happy :)


I just tested the new Aspell. Version 0.6 works fine and more recent 
dictionaries are available compared to 0.5, so I'd prefer the new one :)


These dictionaries do need to be compiled (it looks like it generates 
.rws files) since the only precompiled dictionaries available are 
totally outdated.


I compiled a few of them and it only seems to take a few seconds for 
each dictionary. So it should not be too difficult to compile them all, 
I guess a shell script could do the job (download, extract, make) 
automatically.


Joost

Re: LyX/Win 1.4.0

[Angus Leeming]

Joost Verburg [EMAIL PROTECTED] writes:
 Angus Leeming wrote:
  I'm still mulling over what to do with aspell. If we go for aspell 0.6 
  then it looks like I'll have to supply the dictionaries too. Would make 
  Kevin Atkinson happy :)

 I just tested the new Aspell. Version 0.6 works fine and more recent 
 dictionaries are available compared to 0.5, so I'd prefer the new one :)

 These dictionaries do need to be compiled (it looks like it generates 
 .rws files) since the only precompiled dictionaries available are 
 totally outdated.

Hi, Joost.

can you confirm that the new flavours of LyX compiled with aspell 0.6 work too?

 I compiled a few of them and it only seems to take a few seconds for 
 each dictionary. So it should not be too difficult to compile them all, 
 I guess a shell script could do the job (download, extract, make) 
 automatically.

If you take on the task and mail Kevin so that he can make these things
available to the wider world, then you'll be doing us all a great service.

I see that these dictionaries are packaged up in an installer on Windows. Did
you try that out too?

Angus

Re: LyX/Win 1.4.0

[Lars Gullik Bjønnes]

Angus Leeming <[EMAIL PROTECTED]> writes:

| Grab it from:
| http://wiki.lyx.org/uploads/Windows/LyX140pre/lyx-1.4.0pre_win32_setup_v1.exe
| 
| I anticipate that the installer will have the same bugs as the 1.3.x
| version since the installer code is little different to the previous
| version. (The one real change being that I've removed all tests for
| Perl in the installer.)

Does this contain changes that you want to commit to the repo? If so
please do so that I can spin pre6.

-- 
Lgb

Re: DVI search.

[Lars Gullik Bjønnes]

João Luis Meloni Assirati <[EMAIL PROTECTED]> writes:

| Index: src/LaTeX.C
| ===
| --- src/LaTeX.C   (revision 13280)
| +++ src/LaTeX.C   (working copy)
| @@ -383,7 +383,8 @@
|  
|  int LaTeX::startscript()
|  {
| - string tmp = cmd + ' ' + QuoteName(file) + " > " + os::nulldev();
| + string tmp = cmd + (runparams.srcspecials?(' ' + 
lyxrc.source_specials_switch):"") +
| + ' ' + QuoteName(file) + " > " + os::nulldev();

ostringstream perhaps? At least use temps/foramtting to make the line
look nicer.

| Index: src/converter.h
| ===
| --- src/converter.h   (revision 13280)
| +++ src/converter.h   (working copy)
| @@ -137,7 +138,7 @@
|std::string const & filename);
|   ///
|   bool runLaTeX(Buffer const & buffer, std::string const & command,
| -   OutputParams const &);
| +   std::string const & name, OutputParams const &);

Why not add the name to the OutputParams?
Is 'name' a nice name for this parameter?

|   ///
|   ConverterList converterlist_;
|   ///
| Index: src/lyxrc.C
| ===
| --- src/lyxrc.C   (revision 13280)
| +++ src/lyxrc.C   (working copy)
| @@ -280,6 +282,8 @@
|   preview = PREVIEW_OFF;
|   preview_hashed_labels  = false;
|   preview_scale_factor = "0.9";
| + source_specials_switch = "";
| + dvi_fwsearch_switch = "";

Not needed.

| Index: src/texrow.C
| ===
| --- src/texrow.C  (revision 13280)
| +++ src/texrow.C  (working copy)
| @@ -78,6 +78,39 @@
|  }
|  
|  
| +int TexRow::getRowFromId(int id, int pos) const
| +{
| + RowList::const_iterator cit = rowlist.begin();
| + int diff_id = abs(cit->id() - id);
| + int best_id = cit->id();
| + int diff_pos = abs(cit->pos() - pos);
| + int best_row = cit->rownumber();
| + while (cit != rowlist.end()) {
| + ++cit;

This looks wrong. If cit == rowlist.end() - 1, then ++cit will bring
it to rowlist.end() and all operations on it will be bogus.

Please also change to use a for loop and don't reevaluate
rowlist.end() on each iteration.

-- 
Lgb

Re: DVI search.

[Lars Gullik Bjønnes]

João Luis Meloni Assirati <[EMAIL PROTECTED]> writes:

| Index: src/texrow.h
| ===
| --- src/texrow.h  (revision 13280)
| +++ src/texrow.h  (working copy)
| @@ -46,6 +46,9 @@
|*/
|   bool getIdFromRow(int row, int & id, int & pos) const;
|  
| + /// getRowFromId - find the closest row for a given (id, pos) pair
| + int TexRow::getRowFromId(int id, int pos) const;
| +

This 'TexRow::' is actually a syntax error and will give warning/error
with gcc 4.1.

Note also that I plan to get rid of TexRow completely later, infavour
of unique id's on paragraphs and offsets into the paragraph. Then we
can have dvi files that can contain sourcespecials and we can send
them around and expect the reverse search to work.

-- 
Lgb

Re: LyX/Win 1.4.0

[Angus Leeming]

Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
> | I anticipate that the installer will have the same bugs as the 1.3.x
> | version since the installer code is little different to the previous
> | version. (The one real change being that I've removed all tests for
> | Perl in the installer.)

> Does this contain changes that you want to commit to the repo?

Yes.

> If so please do so that I can spin pre6.

I'm afraid that I can't. When I try and pull over a copy of the repository onto
my Windows box using svn+ssh:

* with TortoiseSVN I get an infinite repeat of dialogs asking for my password.
* using either Cygwin's or the native Windows svn command line, the thing just
hangs. They shouldn't need my password as I have my ssh keys set up (can log on
to aussie with ssh without being prompted for a password).

Interestingly, I did pull over the 1.3.x branch onto my *linux* box using
svn+ssh, so the problem is at my end and with my Windows box rather than at your
end.

The net result is that I finally pulled over the repo using anonsvn; no write
access.

So, could you commit this patch to both the 1.4 branch and to head for me
please? It isn't perfect but it's a monotonic improvement over what exists
currently. I'll try and find some time to tweak it thereafter.

Of course, if you don't commit the patch, that isn't a big deal and shouldn't
hold up pre6. This patch is an update of some build scripts for Windows (I think
of them as both "private to me" and as a "guide to Joe Public") and for the
Installer that is essentially orthogonal to LyX itself. Your call whether
they're needed for pre6.

Angus

Re: Lyx/Win does not accept characters in non-english encoding!

[Angus Leeming]

Stephen Harris <[EMAIL PROTECTED]> writes:
> Angus wrote:
> Ok, you can grab this iconv-aware version of LyX 1.3.7 here:
> http://wiki.lyx.org/uploads/Windows/LyX137/lyx-1.3.7_win32_setup_v3.exe

> This is probably not what is supposed to be tested, but
> the spellchecker fails "The spellchecker has failed! No word
> lists can be found for the language "en"."

As yo suggest, this is all to do with the aspell 0.5 to 0.6 change. aspell 0.6
expects to find its dictionaries in a different location to 0.5. Haven't got
time to help here I'm afraid but the aspell pages are quite explicit (as you
pointed out), so it'd be great if you could install dictionaries in the place
expected by aspell 0.6 and see if you can spell check both flavours of LyX at
the same time.

That's the sort of "release info" we'll need to add to the LyX137 page on the
wiki if we eventually go with this _v3.

Angus

ps, as you say, the real reason for posting this thing was for "code-page
competent" individuals to play with gettext. That's still the case...

A.

Re: LyX/Win 1.4.0

[Angus Leeming]

Stephen Harris <[EMAIL PROTECTED]> writes:
> Angus wrote:
> I anticipate that the installer will have the same bugs as the 1.3.x 
> version since the installer code is little different to the previous 
> version. (The one real change being that I've removed all tests for 
> Perl in the installer.) 

> I got an error message during the install: "Failed attempting to set
> path_prefix in the configure script." And there were no entries in
> Path prefix when I checked under Preferences later.

Right. This is my bad. The support files have changed location (from
Resources/lyx/ to Resources/) and the installer is looking in the old location.
FWIW, I saw this too but it was late, I was tired and I "fixed" it in the same
way that you did :)

Lars, this shouldn't stop you committing the patch :) Please do so and I'll
provide a tweak to the installer thereafter.

Angus

Re: Lyx/Win does not accept characters in non-english encoding!

[Angus Leeming]

Angus Leeming <[EMAIL PROTECTED]> writes:
> As yo suggest, this is all to do with the aspell 0.5 to 0.6 change. aspell 0.6
> expects to find its dictionaries in a different location to 0.5. Haven't got
> time to help here I'm afraid but the aspell pages are quite explicit (as you
> pointed out), so it'd be great if you could install dictionaries in the place
> expected by aspell 0.6 and see if you can spell check both flavours of LyX at
> the same time.

Forgot to add: you can grab dictionaries from
ftp://ftp.gnu.org/gnu/aspell/dict/
E.g.
ftp://ftp.gnu.org/gnu/aspell/dict/en/aspell6-en-6.0-0.tar.bz2
ftp://ftp.gnu.org/gnu/aspell/dict/de/aspell6-de-20030222-1.tar.bz2
ftp://ftp.gnu.org/gnu/aspell/dict/fr/aspell-fr-0.50-3.tar.bz2

My reading of the aspell pages is that aspell 0.6 is perfectly happy with the
0.5 dictionaries so long as they're installed in the "expected" place.

Angus

Re: DVI search.

[Angus Leeming]

João Luis Meloni Assirati <[EMAIL PROTECTED]> writes:
> > * if LyX were able to talk to xdvi through the lyxclient interface, then we
> > wouldn't have to keep creating a new xdvi process in "client" mode each
> > time I click in the LyX window which is what happens now.
> 
> No. We don't create a new xdvi process each time we click in the lyx window.
> View -> DVI remains the only way to start a new xdvi process. Forward search 
> means that this new xdvi will start at the right page. What occours now is 
> that xdvi is called with the option

Sorry to be pedantic, but from LyX's point of view that's "creating a new xdvi"
isn't it? I.e., your "xdvi is called" is my 'system("xdvi option1 option2");'.
Or, eventually, when system() is consigned to the waste bin of history we'll be
using fork() and 'execvp("xdvi", ["xdvi", "option1", "option2", 0]);'

What xdvi itself does with this is a separate matter. (Whether a whole new and
fully-functional instance of xdvi is created or whether the newly created
process just posts the new info to an existing, running xdvi client for it to
update its data.)

Anyway, the whole discussion is just for my academic interest, so don't let my
pedantry bother you :)

> There is also a high level tool to communicate with xdvi, which is xdvi 
> itself 
> (i.e., there is no xdviclient; instead, xdvi itself can work in client mode). 
> It communicates with another running xdvi not through a socket like we do, 
> but through something called "X properties", a native xwindow message passing 
> protocol (the same way emacsclient and 'mozilla -remote' do 
> (http://www.mozilla.org/unix/remote.html)).

Interesting. Thanks. FWIW it appears that Windows apps tend to use a similar
technique to prevent multiple instances of an app from running simultaneously.

> > I think that this is a great piece of work
> > and think it should have gone into the LyX sources a long, long time ago.

> Thanks for the kind words, Angus. I am a theoretical physicist, not a 
> programmer, and all I know about C++ comes from hacking parts of the lyx code 
> and reading some online references in www.lyx.org/devel/references.php.

That sounds like the same route I took into LyX :)

> For me and some of my colleagues, lyx and a web browser are
> the most important software, so I hack lyx because it is
> important to me, in those parts that I think are important to me.
> Therefore I think it is natural that my contributions are not priority.

Well, it seems to me that we've raised the entry bar too high. LyX survives on
contributers like yourself and we should make it easy for them to feel like
"insiders". I'm guessing that etting your code into the repo in less than two
years would have helped enormously to make you feel like an "insider" :)

> > Very well :) http://www.lyx.org/~leeming/William/
> 
> Beautiful. You are a coruja ("owl") like we say in Brazil, meaning a very 
> proud and loving dad (applies to a mom, too)  :).

Less loving this morning as the wee bugger kept us up all night for no good
reason. Pushing at boundaries already :)

Angus

Re: Bugzilla 2315

[Georg Baum]

Lars Gullik Bjønnes wrote:

> 
> This is still not resolved as fixed in bugzilla, shouldn't it be?

No, since the fix is not applied (2315 is not about the mathbb problem, but
about converting stuff to math by C-M). I had no time to test the fix
thoroughly, the current state is that Jürgen tested the patch and found no
problems.


Georg

lyx140cvn: longer error messages

[Hartmut Haase]

If in 
src/converter.C:442 src/format.C:265 src/format.C:310
50 would be replaced by e.g. 80 or more longer text strings could be 
displayed.
E.g. "latex2html -no_subdir -split 0 -show_section_numbers $$i"
has already 55 characters without the file.
-- 
Viele Grüße,
Hartmut Haase

Hungerhilfe: http://www.thehungersite.com

Das heutige Motto:
Beam me up, Scotty. There's no intelligent life down here. 

Re: Trying to use Mingw and Cygwin without Msys

[Enrico Forestieri]

Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> 
> Hello,
> 
> I spent an awful lot of time trying to fix my msys install without
> success so I decided to give cygwin a try. There is a way to use cygwin
> environment with mingw without the -mno-cygwin option (see the mingw FAQ
> at the end of this email). The goal is to produce a package that will
> not need cygwin to run.

Hi Abdel,

I use cygwin with the -mno-cygwin option to build a LyX package which runs
without needing cygwin. I paste at the bottom an uuencoded tar archive
with my notes and a couple of scripts which are modified versions of
similar scripts by Angus. The procedure works for me without a glitch.

To extract the archive simply save this post in a file and run uudecode
on it (cygwin is your friend here):

 uudecode -o lyxwin.tar.gz 

Please, note that I have not installed MinGW for the simple reason that
when you use the -mno-cygwin option you are really using the MinGW
compiler ;-)

In the notes you are instructed to create a C:\MinGW dir which is then
populated during the procedure. You can choose whatever name for that
dir (C:\Aspell, perhaps) but remember to accordingly change every
occurrence of it.

-- 
Enrico


begin 644 lyxwin.tar.gz
M'XL(`)S_!D0``^Q;ZW?32+*?K]?G\#_TB#!.P)+\2`)X2,Z$)$#.F`22L,!9
M[WIDJ6UKT2MZQ/$P_._W5_V09,>!V3V7V2_7X-CJKJZN5U=75;>#Q8T;AXD?
M<"N_R7_X+J\V7KO;V_39>;S3%I_M[8YH;[=[[5VTH:'=V7G\>'L'<)UNK[OS
M`VM_'W*67T66.REC/_#)M^!XFOT5!/VUKX[%7OO1R_?L)S;O=9W$9^YB.OXV.U6$'&9OS9A`P"(+E,Z[AE/6D;.[G,V:&46S*GA8+G4^<
M944*^)C-G^K\'P8HP3B8%%5CB!
MQ.7Q:Q[$2GW(WC],%.^S;@F=[[$?$
M'B':8.$G0#`S6=M](F>>[EMAIL PROTECTED]"US,G44FI.%HBK,9!V^;8R>;[EMAIL PROTECTED]
M2S`6Q3ES0\_B-TH&113P+`/)@<<$=W,?B#87<<$BSCT2&&%68U@<@97&
MT<2?%BEH(,P2V[CP`X]:WN8MEG'.QA#*?,MB!R"'[EMAIL PROTECTED]<3H0!'9+)Y'8$,2
MU\+(G/GX#U)2_]K78L7T+J0]%9(+!3PQ!5MQ?)#24F.4D!UH.L^AH7@"=8^S
MW,^+'.1(7`:_2>(T9Q\^?-C[^/@>-R`C\JAT)MI:XM5+X?UV*%T(F*MD'S)100UOJ2^
M76]Y;MUNV7I5<'9XN->[EMAIL PROTECTED]<5>TSSK"I#ZHVGR
MR!D'W`0MN0]TIN=GLF$&^7BUABC(\)2D?.+?[?49HH;+C^77/WO>RAAS6?

Re: Bugzilla 2315

[Lars Gullik Bjønnes]

Georg Baum <[EMAIL PROTECTED]> writes:

| Lars Gullik Bjønnes wrote:
| 
| > 
| > This is still not resolved as fixed in bugzilla, shouldn't it be?
| 
| No, since the fix is not applied (2315 is not about the mathbb problem, but
| about converting stuff to math by C-M). I had no time to test the fix
| thoroughly, the current state is that Jürgen tested the patch and found no
| problems.

Then someone have to test it promptly or this will not be in 1.4.0.

-- 
Lgb

Re: Bugzilla 2315

[Georg Baum]

Lars Gullik Bjønnes wrote:

> Then someone have to test it promptly or this will not be in 1.4.0.

OK, here is an updated patch for testing (nothing had changed, I only moved
the ChangeLog entry). Any takers?


GeorgIndex: src/ChangeLog
===
--- src/ChangeLog	(Revision 13280)
+++ src/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,7 @@
+2006-02-26  Georg Baum  <[EMAIL PROTECTED]>
+
+	* text3.C (mathDispatch): fix math inset creation from string (bug 2315)
+
 2006-02-28  Martin Vermeer  <[EMAIL PROTECTED]>
 
 	* cursor.C (niceInsert): fix (properly) insertion of
Index: src/text3.C
===
--- src/text3.C	(Revision 13280)
+++ src/text3.C	(Arbeitskopie)
@@ -158,16 +158,17 @@ namespace {
 			// create a macro if we see "\\newcommand"
 			// somewhere, and an ordinary formula
 			// otherwise
+			istringstream is(sel);
 			if (sel.find("\\newcommand") == string::npos
 			&& sel.find("\\def") == string::npos)
 			{
-cur.insert(new MathHullInset("simple"));
-cur.dispatch(FuncRequest(LFUN_RIGHT));
-cur.dispatch(FuncRequest(LFUN_INSERT_MATH, sel));
-			} else {
-istringstream is(sel);
+MathHullInset * formula = new MathHullInset;
+LyXLex lex(0, 0);
+lex.setStream(is);
+formula->read(cur.buffer(), lex);
+cur.insert(formula);
+			} else
 cur.insert(new MathMacroTemplate(is));
-			}
 		}
 		cur.message(N_("Math editor mode"));
 	}

Re: Trying to use Mingw and Cygwin without Msys

[Enrico Forestieri]

Enrico Forestieri <[EMAIL PROTECTED]> writes:

> I use cygwin with the -mno-cygwin option to build a LyX package which runs
> without needing cygwin. I paste at the bottom an uuencoded tar archive

I just noticed that this damn'd gmane interface horribly mangled the
uuencoded archive. I am posting it again using base64 encoding this time.
Same procedure as before for axtracting it.

-- 
Enrico


begin-base64 644 lyxwin.tar.gz
H4sIAJz/BkQAA+xb63fTSLKfr9fn8D/0iDBOwJL8SAJ4SM6EJEDOmASSsMBZ
73pkqW1r0St6xPEw/O/3V/2QZMeB2T2X2S/X4Njqrq6uV1dXVbeDxY0bh4kf
cCu/yX/4Lq82Xrvb2/TZebzTFp/t7Y5ob7d77V20oaHd2Xn8eHsHcJ1ur7vz
A2t/H3KWX0WWOyljP/DJt+B4mv0VBP21r47FXvvRy/fsJzbvdZ3EZ+5iOvcj
ljjuJ2fKs3uNe42O1WEHGZvzZhAwCILlM67hlPWkbO7nM2aGUWzKnhYLnU+c
ZUUK+JjNnGt+r8HwcoCEEFw7qR8XGQv9aDpnTuTdQQHbjAGeYowTiYFFVjiB
xOXxax7EScijHJPEQbbVIpCIZX6YBAvmptzJJb2en3I3j9MFO+zbgmd77EfE
HiHaYOEnQDAzWdt9ImeexEEQg7ZpC1zMnUUmpOFoirMZB2+bYyebsRgEu9ls
SzAWxTlzQ8/iN0oGRRTwLAPJgccEd3MfiDYXccEizj0SGGFWY1gcgZc58eXG
0cSfFiloIMwS27jwA49a3uYtlnHOxhDKfMtiByCH3zgQBcToQBHZLJ5HYEMS
18LInPn4D1JS/9rXYsX0LqQ9FZILBTwxBVtxfJDSUmOUkB1oOs+hoXgCdY+z
3M+LHORIXAa/SeI0Zx8+fNj7+PGjwUi1geNyAjcynvPomjoZdVrS3LrsMpbm
E/gTzriT+TyFZhcJ79c0FhdQuzmBxpjt6nafVAXioJ4WPaxoZw6pwo4c1xUK
gFLf+5EXzzPYGwz4sD/M4pADg6bfyYDcLhuBMsu54xH1NDqMIVa3CMdwD4AB
7GLqQZa8PkiwZf4fvwhn12IDf+zDKq7lY4cdQcNBDAKXDFavJjZJ41AyNsvz
pG/b8/ncmkaFFadTEDzJ57ATe8qh0Jtcf1qzPAy0gAM1oQm30LbgPa3p73Ly
Lju+yVPHzcXc9NazQvx2kaV2ELtOYGepa4tVL4f12KF0ImKtkHzJRQQ1vqS+
XW95bt1u2XpVcHZ4uNecum7dETXZIUyvOX30aKX1xeDg5cVe0zzrCpD6o2ny
yBkH3AQtuQ90pudnsmEG+Xi1hijI8JSkfOLf7GnfUZoobLj+XXP3veyhhzWf
JVxO0PumNWTCHLQlOGKkFfHc1kKXTWbb2m1b26Wuq55dyMnctdqmNITx793l
Xj83YRajbru9097p9upgRF9lMKTxiU9u6ium0hOmolXtlIyW5rFErm5XLubN
weUrZmBVls69v0Ftxl9hRoDsdc2UE1M5tfz7Fkb7q1nav7I3zc46CyR5bbM3
Tu7OaJcO48gmCY/gmwPLTRKx2lSH5JxatTxhUGtHwU/4U/RDpdtmp2N2dlin
1+8+7e9sW239Yo8Q4an1+QgCWzu9epFtmJ2u2WuzLhDt9re76xH98gszu7ut
XfYIfx/jUTYz9XHfn3h8wt6fnPbICNXk92lDcIPC48xwMnfk0h5izZLE0MMq
gGd+bM32q3ag8yPODg4Pjy8u2EhuGWuGzeUGIsbeEl4lWS05zXN71+x2Wftx
v9ft99pLPHfXCK9CVBdah7W3+912f6d9t9C2uyQ0/F0nNC0cP85yBEthXTZa
hkVEkk0QdOQTPVAJ5+j4xcG7weVocHD6Elt9NHp3sTya2TY7Pbs87otgBBYg
AoUk9+NIhiRRPGcZ4jKYvAgh4aeMiWkwac8WY6/iOaK8lGRLJr2zdrdYdQZf
c7w9a3ctDhklukQaQlMZ+pauxbLsVZe3xnF8e/p1CG95yf/W9rFtsbeXPVtH
RC9SxJLHnk8Skd0d9pLL3T1AXJ3l7PBvFwzKyRREyd2yC19xxRh0fnZ2yYx+
gqwKw/tOFEcLxHPZL+51ZmVxkbocUeeU027Ut9GYxnFuX+VYa6XDRisL4ilF
6dTwLOV5kUb7bDOKscFl2TxOva06sPn7U6wmZqbgciQcxaiHf8/PD04PXzHT
u8p77Co3e0zZL3HcVR5UG0i1h0qfTvsBqUZsXi0ZNovgHPBj7LJZgMBZbGt5
LGlRLS1E5i5PSJoxQv3QST/RuIBWFewJAXThkOCt0qkg+pbzWOXUuif0M7ey
QvsbgJjj00it/OxbwEkaT1M4vq/AXZEA1vZLiBfIH2gJL0pJMWccX/OWjNQp
Hh9j6cURbepKwsrRbt5OsFr1dGqrlg9ktGv6zOSsmdnD4XDz7//c+Mdwyx7a
w449bbJnFOGP8nj/Tlbk30skWjJ1gA5rui1zG2RqSMbgu2LXLVLKxbak8yCf
KFaLop4Sp8PDFoUF+PPmjXA3g5PTX6WrW7YnsJ+V3Bwe4s8eW4lBVB+SJepb
jkRUHya5q09MvKavTHEdZHTRNOCVmjbvUq1gGBKA+pwgi5mjkj2a4+3rg1+P
1USWZRnIXH2soLCAv4CeZWZJOe4dY2rEifGawucpzELmFcJ8Kt3IUEZmrMYv
/kRYCL/xMeEzZPX77BnMZd8QUpe4YNUJNiLktJRfu7EHY/QtbrUwXjg201ND
//hDjW4xqXTZXCbfohOkLKiggZQTeaEL/5VxSr+zMpF242Rh7rtJC1YSmPtp
iPWfu5Z0Mj3hZcvknltjJy/DM6ptxMjTN8cLkTiTrRj9PhOZNOL3SKWiofJ1
wjvDi2BhzbgrnArZoa7KVCusNDYgg8weCB1cvDk+fMD29mrubbOEYupTxpyC
QKkmL8Z0JHT43E8teOX4k5hUynd5vPHg7eXRyfmDIbmXIVaMR+uy/GJopexH
RbA8EkTyNI3TgKo+rLNKmH5hl2HEyp5IHMBEtY1q0C3GAyq4rEfA3Vls3d2l
2F/iWS5oJQ2zPjG6i8AT5RzJmMlgFSkP42v+lTmGEtdwLJUcsgWMSiYxVDgT
OQQEnCKLCLEmeJjEKexPgik6oGePp3dwMo3zmB2fn5+dr4imfNySxqlziPAT
whU3s0vDsIVzsMhqWyyMPX+yIGPTtT0iMSNzk0UnUZNStNQXxu2NUlRiiC0q
kJEZzZ3U09tmuR0Kax0JP1l73eEyFTA5zmXgdX5SAgtv+WeBD8/efFwGdhNm
Tuogr8/+drwMEl6vgBwdD0YvTgbHFUgaroAcvvp1hMUzOv5wcnF5QSDKWy1N
9StAlqdSxU2p0R2lUencZTBeZoSyccojnjoIy5W+ZRI+kgqnLJHwbmaFS7sY
OSumRsCx692CbD5jTbtJRiCqaxlPHIFVV9EkHviv5rC5tc41bSAin0xYRaPM
oqpnCdZ7uuvirTyyYvtMAPX7YH2EmSEGYzg0fi5TNPll/25om4CX6FiWgqRl
nWSedN0n3To1by9yUbMlubwhUeyVE8K3J0U+IgU9Ym+P/LTfL+W0uYU2GnOK
5bCe8j+LeZW/W3g73acu3ssypBc20We0ol8GBd809Op4DhszWoY5GBr4GBqs
/GZs0QCD3Snq/wyplXJRN95sDofNFsyqNo20613tqZaj4dDxpXnD6ShjRbph
5jPkux7sVVVg3uY6EqV6eq5MXEQ30luzy4Png+NLxIGJqGhjP0bE5xRBvmUh
aPSFkWN6fIk41QrIH4+562AdVPGgqBJj5gwb95VO6hCpCM9XVvJfl6FNGSnK
jFuJ9AgZzOWr8+ODo9HFuzdvzs4vKcKO5CEBQZvwU5JDtViIrKkPGOuWTa+V
ljbutZ3KYtodF+9Vi5F5GDPqu+BXbKEEr4H1nrRdvJcxf2aG5AihmFGyh4c2
+9K6A/2dYzrlmJ12z8W7PpeqT1hvX8deQUrY08tsAE1hfSaBn2+S7QFrli8C
sVXFAR0oCJF/4mmEEGXue1MOzXq+g0QVGqbanc/nImTIEjoEQX4r4geY3jX8
nywO3oQBaOCIxVl2FajDCn/sY9aFBMlhR0XkGWxrvWD/cw6+J+krNHc6290W
/vTc8ltdCxNZcdqk6BdUsofgUsnXqr3KWo5aKQJArVGL3fkaRhUh6+cjqVar
qJrvKI6auT74XDfrN+dbUda6ib8Po+vne/hdGJU++bHI/skj1UpF0g2fyAQF
HljQcSIzyZkjjj8dz5OuUpcomyqnRh8dCkgzta+cBJbsikrJaO5XYUwdZhJH
ue5cjSzWIZCub12PHLr92Nl+0tp+qmVaVlGfiYoXL6vI9S5Ved5fnb9OnJq4
3iSBd7ed3Z2vTkeyfsIOq/PuqrCQLUKq+LBNeWpLB8zyiFnjIXBMPMvZJIid
3JptVUQGSGcyWc5T4DIUrFf4ljq04p+W5kro317S2R1lKGWFQ5E6j5lId1WR
xZfbVx4npkzzqnN7deKKfTpPOVfeW0ZftzPnWlRGTeJonbb3zJnwABs38n9d
01NBqKpJ09n3MrYJlawNdVBjyENzLxaSjVW2rTgjPHOfEhoujbfHXo9Z4KRT
ntYrVTCqdYSrkr3I/+KJivspmy0z872VgpVLLMiqag2a0us9mWX3h3v2AwW7

Re: Bugzilla 2315

[Enrico Forestieri]

Georg Baum <[EMAIL PROTECTED]> writes:
> 
> Lars Gullik Bjønnes wrote:
> 
> > Then someone have to test it promptly or this will not be in 1.4.0.
> 
> OK, here is an updated patch for testing (nothing had changed, I only moved
> the ChangeLog entry). Any takers?

With this patch the behavior is as in 1.3.7, including that when selecting a
math inset and pasting it outside of LyX, the delimiters are still left out.

Given that, I don't know why this patch is needed...

-- 
Enrico

Re: Bugzilla 2315

[Georg Baum]

Lars Gullik Bjønnes wrote:

> Then someone have to test it promptly or this will not be in 1.4.0.

Actually I think that John set the 1.4.0 target because at that time we
thought that math-insert was broken in general. Fortunately thsi has now
been resolved.
For me it is not too important to have this in 1.4.0. Maybe we should create
a fix that does not completely revert to 1.3 behaviour (always require
delimters), but makes it possible to convert with or without delimiters.


Georg

Re: Bugzilla 2315

[Juergen Spitzmueller]

Enrico Forestieri wrote:
> With this patch the behavior is as in 1.3.7, including that when selecting
> a math inset and pasting it outside of LyX, the delimiters are still left
> out.
>
> Given that, I don't know why this patch is needed...

try this:
1. write \text{test} in text mode
2. select it
3. hit C-M

you get an ampty text inset. The patch fixes that.

The bug is not about copy and paste, but about text->math conversion.

Jürgen

Re: Bugzilla 2315

[Lars Gullik Bjønnes]

Georg Baum <[EMAIL PROTECTED]> writes:

| Lars Gullik Bjønnes wrote:
| 
| > Then someone have to test it promptly or this will not be in 1.4.0.
| 
| Actually I think that John set the 1.4.0 target because at that time we
| thought that math-insert was broken in general. Fortunately thsi has now
| been resolved.
| For me it is not too important to have this in 1.4.0. Maybe we should create
| a fix that does not completely revert to 1.3 behaviour (always require
| delimters), but makes it possible to convert with or without delimiters.

Ok.

To make thing trot along I'll move this (2315) to 1.4.1.

Please do not commit the 2315 patch.

-- 
Lgb

Re: Bugzilla 2315

[Georg Baum]

Juergen Spitzmueller wrote:

> Enrico Forestieri wrote:
>> With this patch the behavior is as in 1.3.7, including that when
>> selecting a math inset and pasting it outside of LyX, the delimiters are
>> still left out.

Enrico, could you file the paste outside of LyX bug in bugzilla, please (or
si it alreday there?)

>> Given that, I don't know why this patch is needed...
> 
> try this:
> 1. write \text{test} in text mode
> 2. select it
> 3. hit C-M
> 
> you get an ampty text inset. The patch fixes that.

OK, forget my previous post about being this no 1.4.0 stuff. I was confused.
Here is a better patch (only two code lines were changed), that does allow
all these cases:

\text{test}
$\text{test}$
\[\text{test}\]
\begin{align}\text{test}\end{align}

etc. Of course \text{test} can be replaced by anything that can be in a math
formula.

Jürgen, Enrico, it would be nice if you could test this one again, so that
it can go in 1.4.0. For me it does work.

> The bug is not about copy and paste, but about text->math conversion.

Yes.


GeorgIndex: src/ChangeLog
===
--- src/ChangeLog	(Revision 13280)
+++ src/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,7 @@
+2006-02-26  Georg Baum  <[EMAIL PROTECTED]>
+
+	* text3.C (mathDispatch): fix math inset creation from string (bug 2315)
+
 2006-02-28  Martin Vermeer  <[EMAIL PROTECTED]>
 
 	* cursor.C (niceInsert): fix (properly) insertion of
Index: src/text3.C
===
--- src/text3.C	(Revision 13280)
+++ src/text3.C	(Arbeitskopie)
@@ -158,16 +158,21 @@ namespace {
 			// create a macro if we see "\\newcommand"
 			// somewhere, and an ordinary formula
 			// otherwise
+			istringstream is(sel);
 			if (sel.find("\\newcommand") == string::npos
 			&& sel.find("\\def") == string::npos)
 			{
-cur.insert(new MathHullInset("simple"));
-cur.dispatch(FuncRequest(LFUN_RIGHT));
-cur.dispatch(FuncRequest(LFUN_INSERT_MATH, sel));
-			} else {
-istringstream is(sel);
+MathHullInset * formula = new MathHullInset;
+LyXLex lex(0, 0);
+lex.setStream(is);
+formula->read(cur.buffer(), lex);
+if (formula->getType() == "none")
+	// Don't create pseudo formulas if
+	// delimiters are left out
+	formula->mutate("simple");
+cur.insert(formula);
+			} else
 cur.insert(new MathMacroTemplate(is));
-			}
 		}
 		cur.message(N_("Math editor mode"));
 	}

Re: Bugzilla 2315

[Enrico Forestieri]

Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
> 
> try this:
> 1. write \text{test} in text mode
> 2. select it
> 3. hit C-M
> 
> you get an ampty text inset. The patch fixes that.

Yes, I was missing that. Then I would say that the patch works, even if
it is a small nuisance that now you have to include some delimiter in
the selection before hitting C-M.

-- 
Enrico

Re: Bugzilla 2315

[Juergen Spitzmueller]

Georg Baum wrote:
> Jürgen, Enrico, it would be nice if you could test this one again, so that
> it can go in 1.4.0. For me it does work.

I'll test intensely now. Lars, I agree with Georg that this should be applied, 
given that it proves good (and it's not too late yet).

Jürgen

Re: Bugzilla 2315

[Georg Baum]

Lars Gullik Bjønnes wrote:

> To make thing trot along I'll move this (2315) to 1.4.1.
> 
> Please do not commit the 2315 patch.

OK. Since Jürgen has pointed out that there was a bigger problem than I
thought (sorry again for the confusion), I would really like an entry in
the release notes.

May I commit the attached instead?


GeorgIndex: RELEASE-NOTES
===
--- RELEASE-NOTES	(Revision 13280)
+++ RELEASE-NOTES	(Arbeitskopie)
@@ -45,3 +45,6 @@ they have not yet been applied because o
   http://bugzilla.lyx.org/show_bug.cgi?id=2284
   http://bugzilla.lyx.org/show_bug.cgi?id=2242
 
+- Text -> math conversion does sometimes not work
+  http://bugzilla.lyx.org/show_bug.cgi?id=2315
+

Re: Bugzilla 2315

[Enrico Forestieri]

Georg Baum <[EMAIL PROTECTED]> writes:
> 
> Enrico, could you file the paste outside of LyX bug in bugzilla, please (or
> si it alreday there?)

I'll do that.

> Here is a better patch (only two code lines were changed), that does allow
> all these cases:
> 
> \text{test}
> $\text{test}$
> \[\text{test}\]
> \begin{align}\text{test}\end{align}

I think that these particular examples already worked with the previous
patch.

> etc. Of course \text{test} can be replaced by anything that can be in a math
> formula.
> 
> Jürgen, Enrico, it would be nice if you could test this one again, so that
> it can go in 1.4.0. For me it does work.

Ok.

-- 
Enrico

Re: Bugzilla 2315

[Lars Gullik Bjønnes]

Georg Baum <[EMAIL PROTECTED]> writes:

| Juergen Spitzmueller wrote:
| 
| > Enrico Forestieri wrote:
| >> With this patch the behavior is as in 1.3.7, including that when
| >> selecting a math inset and pasting it outside of LyX, the delimiters are
| >> still left out.
| 
| Enrico, could you file the paste outside of LyX bug in bugzilla, please (or
| si it alreday there?)
| 
| >> Given that, I don't know why this patch is needed...
| > 
| > try this:
| > 1. write \text{test} in text mode
| > 2. select it
| > 3. hit C-M
| > 
| > you get an ampty text inset. The patch fixes that.
| 
| OK, forget my previous post about being this no 1.4.0 stuff. I was confused.
| Here is a better patch (only two code lines were changed), that does allow
| all these cases:
| 
| \text{test}
| $\text{test}$
| \[\text{test}\]
| \begin{align}\text{test}\end{align}
| 
| etc. Of course \text{test} can be replaced by anything that can be in a math
| formula.
| 
| Jürgen, Enrico, it would be nice if you could test this one again, so that
| it can go in 1.4.0. For me it does work.
| 
| > The bug is not about copy and paste, but about text->math conversion.

Ok count me confused.

Please all, make up your mind about this bug. Required for 1.4.0 or
not.

-- 
Lgb

Re: Bugzilla 2315

[Lars Gullik Bjønnes]

Juergen Spitzmueller <[EMAIL PROTECTED]> writes:

| Georg Baum wrote:
| > Jürgen, Enrico, it would be nice if you could test this one again, so that
| > it can go in 1.4.0. For me it does work.
| 
| I'll test intensely now. Lars, I agree with Georg that this should be 
applied, 
| given that it proves good (and it's not too late yet).

I'll hold off pre6 some hours yet.

-- 
Lgb

Re: Bugzilla 2315

[Juergen Spitzmueller]

Lars Gullik Bjønnes wrote:
> Please all, make up your mind about this bug. Required for 1.4.0 or
> not.

I did already (required for 1.4.0)

Just testing ...

Jürgen

Re: Bugzilla 2315

[Enrico Forestieri]

Georg Baum <[EMAIL PROTECTED]> writes:
> 
> Jürgen, Enrico, it would be nice if you could test this one again, so that
> it can go in 1.4.0. For me it does work.

The new patch seems to work. However, if the selection does not include
any delimiter I get some messages on the terminal. For example, selecting
$\alpha$ and hitting C-M is fine, but simply selecting \alpha and then C-M
gives the following message:

unusual contents found: [symbol alpha]

even if the conversion does work. I tried several normal and AMS math
environments and everything seems to be fine (with warnings when a
delimiter is missing).

Then I tried something unusual, i.e., I selected "$a$ foo $b$" (double
quotes excluded) and hit C-M. Everything seemed to be translated in math
mode but exporting to latex revealed that I had got

$$a$ foo $b$$

which is clearly incorrect. The message on the console in this case was:

unusual contents found: [formula simple [grid [row [cell [char a mathalpha]
[char   mathalpha][char f mathalpha][char o mathalpha][char o mathalpha][char   
mathalpha][formula simple [grid [row [cell [char b mathalpha]

To be honest I don't know if this can be regarded as a bug, as I have
no opinions on what should have happened. Anyway, the generated latex
is incorrect.

-- 
Enrico

Re: Bugzilla 2315

[Jose' Matos]

On Thursday 02 March 2006 17:37, Enrico Forestieri wrote:
> To be honest I don't know if this can be regarded as a bug, as I have
> no opinions on what should have happened. Anyway, the generated latex
> is incorrect.

  This is not a regression either because this happened for 1.3.x as well, 
IIRC. At least for now that is the major concern. :-)

> --
> Enrico

-- 
José Abílio

Re: Bugzilla 2315

[Juergen Spitzmueller]

Jose' Matos wrote:
> > To be honest I don't know if this can be regarded as a bug, as I have
> > no opinions on what should have happened. Anyway, the generated latex
> > is incorrect.
>
>   This is not a regression either because this happened for 1.3.x as well,
> IIRC. At least for now that is the major concern. :-)

No, in 1.3, it has been correctly converted to
$a$ foo $b$
because everything without $-delimters has been regarded as math-TEXT.

But I guess this is the price to pay for the freedom of using delimiters or 
not. However, it seems to me that at least
$a$ $foo$ $b$
would be more sensible.

However, I agree that we could live with this minor glitch in 1.4.0

Jürgen

Re: Bugzilla 2315

[Enrico Forestieri]

Georg Baum <[EMAIL PROTECTED]> writes:
> 
> Juergen Spitzmueller wrote:
> 
> > Enrico Forestieri wrote:
> >> With this patch the behavior is as in 1.3.7, including that when
> >> selecting a math inset and pasting it outside of LyX, the delimiters are
> >> still left out.
> 
> Enrico, could you file the paste outside of LyX bug in bugzilla, please (or
> si it alreday there?)

It is now bug 2342.

http://bugzilla.lyx.org/show_bug.cgi?id=2342

-- 
Enrico

Re: LyX/Win 1.4.0

[Angus Leeming]

Angus Leeming wrote:

Grab it from:
http://wiki.lyx.org/uploads/Windows/LyX140pre/lyx-1.4.0pre_win32_setup_v1.exe 

I anticipate that the installer will have the same bugs as the 1.3.x 
version since the installer code is little different to the previous 
version. (The one real change being that I've removed all tests for Perl 
in the installer.)


I found some time to investigate the problems with the insertion of the 
path_prefix entry. As a result, I've squashed the numerous bugs in 
lyx_configure.C. At the very least, the new version should give us an 
informative error message, albeit one that's output to console for now.


The new version is at
http://wiki.lyx.org/uploads/Windows/LyX140pre/lyx-1.4.0pre_win32_setup_v2.exe

Lars, I'm going to reboot this machine into linux right now so that I can 
apply and commit the changes to both head and to the 1.4 branch. Jean-Marc, 
if you're OK, I'll also commit a part of this patch to the 1.3 branch; 
lyx_configure.C is compiled into a .dll and it would be nice to use the 
same one for both the 1.3 and 1.4 installers.


Patch attached for info.

Angus



packaging.diff.bz2
Description: Binary data

Re: Bugzilla 2315

[Juergen Spitzmueller]

Georg Baum wrote:
> Jürgen, Enrico, it would be nice if you could test this one again, so that
> it can go in 1.4.0. For me it does work.

It works for me, except for the glitch Enrico reported, and the following 
issue of which I'm not sure if it is related:

1. Insert formula
2. type "foo"
3. mark "foo"
4. hit C-M

you get an empty math-text inset. 1.3 copied the selected content inside the 
inset. Same problem vice versa (C-m with marked text inside math-text).

However, this issue happens with or without the patch, so the patch basically 
works for what it is advertised.

Jürgen

Re: Bugzilla 2315

[Georg Baum]

Juergen Spitzmueller wrote:

> Georg Baum wrote:
>> Jürgen, Enrico, it would be nice if you could test this one again, so
>> that it can go in 1.4.0. For me it does work.
> 
> It works for me, except for the glitch Enrico reported, and the following
> issue of which I'm not sure if it is related:
> 
> 1. Insert formula
> 2. type "foo"
> 3. mark "foo"
> 4. hit C-M
> 
> you get an empty math-text inset. 1.3 copied the selected content inside
> the inset. Same problem vice versa (C-m with marked text inside
> math-text).
> 
> However, this issue happens with or without the patch, so the patch
> basically works for what it is advertised.

So it is not related to the patch.

Enrico and Jürgen, thanks for your testing.

Summary:

The patch fixes the C-M text->math conversion for all tested cases of
_valid_ math formulas, with or without delimiters. It has the following
drawbacks:
1) It creates a warning on the console if a formula without delimiters is
converted.
2) It produces invalid results for things that are not really _one_ formula,
e.g. the mentioned $a$ foo $b$.

1) is not the case currently in 1.4, but is IMHO a good trade-off wrt the
currently not working \text{test} conversion.
2) is a regression wrt. 1.3, but IMHO not important because this kind of
pseudo formulas has never been officially supported.

This is IMHO enough data now to make a decision. I'd say that the patch can
go in, because the advantages clearly outweigh the disadvantages.

Lars, what is your opinion?


Georg

[PATCHES 13x, 14x, head] The updated Windows installer stuff

[Angus Leeming]

Attached are the patches that I'd like to apply to the repository. The
patches for the 1.4.x branch and for head are identical. The patch for the
1.3.x branch is simply the cleaned up lyx_configure.C file backported from
1.4.x/head. It allows the 1.3.x installer to use the same
lyx_configure.dll and (more importantly) fixes the broken setting of the
path_prefix variable in lyxrc.defaults.

I'll apply the patches to 14x and to head now. I'll wait on JMarc's say so
for the 13x patch.

-- 
Angus

win_packaging_13x.diff.bz2
Description: BZip2 compressed data


win_packaging_14x.diff.bz2
Description: BZip2 compressed data


win_packaging_head.diff.bz2
Description: BZip2 compressed data

Re: [PATCHES 13x, 14x, head] The updated Windows installer stuff

[Angus Leeming]

Angus Leeming wrote:

> Attached are the patches that I'd like to apply to the repository. The
> patches for the 1.4.x branch and for head are identical. The patch for
> the 1.3.x branch is simply the cleaned up lyx_configure.C file backported
> from 1.4.x/head. It allows the 1.3.x installer to use the same
> lyx_configure.dll and (more importantly) fixes the broken setting of the
> path_prefix variable in lyxrc.defaults.

> I'll apply the patches to 14x and to head now. I'll wait on JMarc's say
> so for the 13x patch.

Ok, Lars, I've committed. pre6 is now ready to roll from my end.

-- 
Angus

Re: Bugzilla 2315

[Lars Gullik Bjønnes]

Georg Baum <[EMAIL PROTECTED]> writes:

| Juergen Spitzmueller wrote:
| 
| > Georg Baum wrote:
| >> Jürgen, Enrico, it would be nice if you could test this one again, so
| >> that it can go in 1.4.0. For me it does work.
| > 
| > It works for me, except for the glitch Enrico reported, and the following
| > issue of which I'm not sure if it is related:
| > 
| > 1. Insert formula
| > 2. type "foo"
| > 3. mark "foo"
| > 4. hit C-M
| > 
| > you get an empty math-text inset. 1.3 copied the selected content inside
| > the inset. Same problem vice versa (C-m with marked text inside
| > math-text).
| > 
| > However, this issue happens with or without the patch, so the patch
| > basically works for what it is advertised.
| 
| So it is not related to the patch.
| 
| Enrico and Jürgen, thanks for your testing.
| 
| Summary:
| 
| The patch fixes the C-M text->math conversion for all tested cases of
| _valid_ math formulas, with or without delimiters. It has the following
| drawbacks:
| 1) It creates a warning on the console if a formula without delimiters is
| converted.
| 2) It produces invalid results for things that are not really _one_ formula,
| e.g. the mentioned $a$ foo $b$.
| 
| 1) is not the case currently in 1.4, but is IMHO a good trade-off wrt the
| currently not working \text{test} conversion.
| 2) is a regression wrt. 1.3, but IMHO not important because this kind of
| pseudo formulas has never been officially supported.
| 
| This is IMHO enough data now to make a decision. I'd say that the patch can
| go in, because the advantages clearly outweigh the disadvantages.
| 
| Lars, what is your opinion?

Put it in please.

Maintrunk first and then merge the revision to the branch.

-- 
Lgb

Re: Bugzilla 2315

[Georg Baum]

Am Donnerstag, 2. März 2006 20:22 schrieb Lars Gullik Bjønnes:
> Put it in please.
> 
> Maintrunk first and then merge the revision to the branch.

Done. I had to look up the options of svn merge because I don't use it 
that often, but it looks like it has worked.


Georg

Re: Bugzilla 2315

[Angus Leeming]

Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
> Put it in please.
> Maintrunk first and then merge the revision to the branch.

Now I know I should go and read the subversion docs, but is this "merge to the
branch" actually:

cd head
svn diff > head.diff
svn commit
cd ../14x
patch -p0 < ../head/head.diff
svn commit

(which is what I've just done with the windows installer stuff)

Or is it some subversion magic?

Angus

Re: Bugzilla 2315

[Georg Baum]

Am Donnerstag, 2. März 2006 21:12 schrieb Angus Leeming:
> Now I know I should go and read the subversion docs, but is this "merge 
to the
> branch" actually:
> 
> cd head
> svn diff > head.diff
> svn commit
> cd ../14x
> patch -p0 < ../head/head.diff
> svn commit
> 
> (which is what I've just done with the windows installer stuff)
> 
> Or is it some subversion magic?

I did:

svn merge -r 13285:13286  svn+ssh://[EMAIL PROTECTED]/lyx/lyx-devel/trunk
svn commit

I do not know the advantages over the diff method (that I have used until 
now), because I did not yet merge that often with svn.


Georg

Re: [PATCHES 13x, 14x, head] The updated Windows installer stuff

[Jean-Marc Lasgouttes]

> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:

Angus> I'll apply the patches to 14x and to head now. I'll wait on
Angus> JMarc's say so for the 13x patch.

You can apply the 13x patch. I won't use for a 1.3.8 anyway, but it is
useful to keep things in one place.

Will you release a new 1.3.7 installer?

JMarc

Re: DVI search.

[João Luis Meloni Assirati]

Em Qui 02 Mar 2006 05:19, Lars Gullik Bjønnes escreveu:
> João Luis Meloni Assirati <[EMAIL PROTECTED]> writes:
> | Index: src/LaTeX.C
> | ===
> | --- src/LaTeX.C (revision 13280)
> | +++ src/LaTeX.C (working copy)
> | @@ -383,7 +383,8 @@
> |
> |  int LaTeX::startscript()
> |  {
> | -   string tmp = cmd + ' ' + QuoteName(file) + " > " + os::nulldev();
> | +   string tmp = cmd + (runparams.srcspecials?(' ' +
> | lyxrc.source_specials_switch):"") + +   ' ' + QuoteName(file) + 
> " > " +
> | os::nulldev();
>
> ostringstream perhaps? At least use temps/foramtting to make the line
> look nicer.

Changed to:

string tmp = cmd;
if (runparams.srcspecials)
tmp += ' ' + lyxrc.source_specials_switch;
tmp += ' ' + QuoteName(file) + " > " + os::nulldev();

>
> | Index: src/converter.h
> | ===
> | --- src/converter.h (revision 13280)
> | +++ src/converter.h (working copy)
> | @@ -137,7 +138,7 @@
> |  std::string const & filename);
> | ///
> | bool runLaTeX(Buffer const & buffer, std::string const & command,
> | - OutputParams const &);
> | + std::string const & name, OutputParams const &);
>
> Why not add the name to the OutputParams?
> Is 'name' a nice name for this parameter?

I moved it to OutputParams under the name latexfile. This allows for some 
cleanups, as for example

LaTeX::LaTeX(string const & latex, OutputParams const & rp,
 string const & f, string const & p)
: cmd(latex), file(f), path(p), runparams(rp)

(file can be taken now from rp), but I will not touch this.

>
> | ///
> | ConverterList converterlist_;
> | ///
> | Index: src/lyxrc.C
> | ===
> | --- src/lyxrc.C (revision 13280)
> | +++ src/lyxrc.C (working copy)
> | @@ -280,6 +282,8 @@
> | preview = PREVIEW_OFF;
> | preview_hashed_labels  = false;
> | preview_scale_factor = "0.9";
> | +   source_specials_switch = "";
> | +   dvi_fwsearch_switch = "";
>
> Not needed.

OK, removed. Note that we have also

roman_font_name = "";
sans_font_name = "";
typewriter_font_name = "";

in LyXRC::setDefaults().

>
> | Index: src/texrow.C
> | ===
> | --- src/texrow.C(revision 13280)
> | +++ src/texrow.C(working copy)
> | @@ -78,6 +78,39 @@
> |  }
> |
> |
> | +int TexRow::getRowFromId(int id, int pos) const
> | +{
> | +   RowList::const_iterator cit = rowlist.begin();
> | +   int diff_id = abs(cit->id() - id);
> | +   int best_id = cit->id();
> | +   int diff_pos = abs(cit->pos() - pos);
> | +   int best_row = cit->rownumber();
> | +   while (cit != rowlist.end()) {
> | +   ++cit;
>
> This looks wrong. If cit == rowlist.end() - 1, then ++cit will bring
> it to rowlist.end() and all operations on it will be bogus.
>
> Please also change to use a for loop and don't reevaluate
> rowlist.end() on each iteration.

Thanks on this. I think it is better now:

int TexRow::getRowFromId(int id, int pos) const
{
RowList::const_iterator cit = rowlist.begin();
RowList::const_iterator rowlist_end = rowlist.end();
[...]
for (++cit; cit != rowlist_end; ++cit) {
[...]
}
return best_row;
}


Attached is the updated patch.

Thanks,
João.
Index: src/BufferView.h
===
--- src/BufferView.h	(revision 13280)
+++ src/BufferView.h	(working copy)
@@ -179,6 +179,8 @@
 	int offset_ref() const;
 	/// access to anchor
 	lyx::pit_type anchor_ref() const;
+	/// access to the texrow corresponding to the beginning of the view
+	int texrow_ref() const;
 
 	/// access to full cursor
 	LCursor & cursor();
Index: src/BufferView.C
===
--- src/BufferView.C	(revision 13280)
+++ src/BufferView.C	(working copy)
@@ -387,6 +387,13 @@
 }
 
 
+int BufferView::texrow_ref() const 
+{
+	return buffer()->texrow().getRowFromId(
+		buffer()->paragraphs()[anchor_ref()].id(), offset_ref());
+}
+
+
 int BufferView::offset_ref() const
 {
 	return pimpl_->offset_ref_;
Index: src/LaTeX.C
===
--- src/LaTeX.C	(revision 13280)
+++ src/LaTeX.C	(working copy)
@@ -383,7 +383,10 @@
 
 int LaTeX::startscript()
 {
-	string tmp = cmd + ' ' + QuoteName(file) + " > " + os::nulldev();
+	string tmp = cmd;
+	if (runparams.srcspecials)
+		tmp += ' ' + lyxrc.source_specials_switch;
+	tmp += ' ' + QuoteName(file) + " > " + os::nulldev();
 	Systemcall one;
 	return one.startscript(Systemcall::Wait, tmp);
 }
Index: src/buffer.C
===
--- src/buffer.C	(revision 13280)
+++ 

Re: DVI search.

[João Luis Meloni Assirati]

Em Qui 02 Mar 2006 05:22, Lars Gullik Bjønnes escreveu:
> João Luis Meloni Assirati <[EMAIL PROTECTED]> writes:
> | Index: src/texrow.h
> | ===
> | --- src/texrow.h(revision 13280)
> | +++ src/texrow.h(working copy)
> | @@ -46,6 +46,9 @@
> |  */
> | bool getIdFromRow(int row, int & id, int & pos) const;
> |
> | +   /// getRowFromId - find the closest row for a given (id, pos) pair
> | +   int TexRow::getRowFromId(int id, int pos) const;
> | +
>
> This 'TexRow::' is actually a syntax error and will give warning/error
> with gcc 4.1.

I don't get it. What is the problem?

> Note also that I plan to get rid of TexRow completely later, infavour
> of unique id's on paragraphs and offsets into the paragraph. Then we
> can have dvi files that can contain sourcespecials and we can send
> them around and expect the reverse search to work.

Latex reports errors in terms of rows in the latex file. How then do you plan 
to map rows into ids a and offsets in order to locate those errors?

João.

Re: DVI search.

[Jose' Matos]

On Thursday 02 March 2006 21:32, João Luis Meloni Assirati wrote:

Olá João, :-)
 (Oi seria melhor ? ;-)

> > | Index: src/texrow.h
> > | ===
> > | --- src/texrow.h  (revision 13280)
> > | +++ src/texrow.h  (working copy)
> > | @@ -46,6 +46,9 @@
> > |*/
> > |   bool getIdFromRow(int row, int & id, int & pos) const;
> > |
> > | + /// getRowFromId - find the closest row for a given (id, pos) pair
> > | + int TexRow::getRowFromId(int id, int pos) const;
> > | +
> >
> > This 'TexRow::' is actually a syntax error and will give warning/error
> > with gcc 4.1.
>
> I don't get it. What is the problem?

class TexRow {
...
int TexRow::getRowFromId(int id, int pos) const;
...
}

The use of TexRow classifier inside the class is wrong, since the function is 
declared there. The right syntax is:

class TexRow {
...
int getRowFromId(int id, int pos) const;
...
}

> João.

-- 
José Abílio

Re: Bugzilla 2315

[Martin Vermeer]

On Thu, Mar 02, 2006 at 08:04:33PM +0100, Georg Baum wrote:
> Juergen Spitzmueller wrote:
> 
> > Georg Baum wrote:

...

> 2) It produces invalid results for things that are not really _one_ formula,
> e.g. the mentioned $a$ foo $b$.

Actually a simple fix that comes to my mind is to simply strip out all
internal dollar signs before trying to parse the string.

Then, in an earlier patch of mine posted on the list, the MathFontInset
output routine would again add the dollar signs around any equations
found embedded in \textrm-like fontinsets, which is the only place they
are required.

- Martin



pgpXALnRBT89s.pgp
Description: PGP signature

Re: DVI search.

[João Luis Meloni Assirati]

Em Qui 02 Mar 2006 07:31, Angus Leeming escreveu:
> João Luis Meloni Assirati <[EMAIL PROTECTED]> writes:
> > > * if LyX were able to talk to xdvi through the lyxclient interface,
> > > then we wouldn't have to keep creating a new xdvi process in "client"
> > > mode each time I click in the LyX window which is what happens now.
> >
> > No. We don't create a new xdvi process each time we click in the lyx
> > window. View -> DVI remains the only way to start a new xdvi process.
> > Forward search means that this new xdvi will start at the right page.
> > What occours now is that xdvi is called with the option
>
> Sorry to be pedantic, but from LyX's point of view that's "creating a new
> xdvi" isn't it? I.e., your "xdvi is called" is my 'system("xdvi option1
> option2");'. Or, eventually, when system() is consigned to the waste bin of
> history we'll be using fork() and 'execvp("xdvi", ["xdvi", "option1",
> "option2", 0]);'
>
> What xdvi itself does with this is a separate matter. (Whether a whole new
> and fully-functional instance of xdvi is created or whether the newly
> created process just posts the new info to an existing, running xdvi client
> for it to update its data.)

You are right.

I was trying to say that forward search is not as interactive as inverse 
search. In inverse search, you can scroll xdvi up or down and control-click 
in the xdvi window to make lyx search the corresponding text. In forward 
search, you have to scroll to the desired point in the lyx window then call  
View -> DVI. There is no interface like "control-click in the lyx window to 
get xdvi to jump to the desired location". That is a cool idea, though.


> Anyway, the whole discussion is just for my academic interest, so don't let
> my pedantry bother you :)

It won't!

> > There is also a high level tool to communicate with xdvi, which is xdvi
> > itself (i.e., there is no xdviclient; instead, xdvi itself can work in
> > client mode). It communicates with another running xdvi not through a
> > socket like we do, but through something called "X properties", a native
> > xwindow message passing protocol (the same way emacsclient and 'mozilla
> > -remote' do
> > (http://www.mozilla.org/unix/remote.html)).
>
> Interesting. Thanks. FWIW it appears that Windows apps tend to use a
> similar technique to prevent multiple instances of an app from running
> simultaneously.

The network transparency of Xwindow system sometimes makes this feature 
confusing. For example, if you want to have two mozillas runing in the same 
display, one runing locally and the other runing on another computer, you 
have to avoid this mechanism. I've been through this.

> > Beautiful. You are a coruja ("owl") like we say in Brazil, meaning a very
> > proud and loving dad (applies to a mom, too)  :).
>
> Less loving this morning as the wee bugger kept us up all night for no good
> reason. Pushing at boundaries already :)

I wish you a better night today :).

>
> Angus

João.

Re: [PATCHES 13x, 14x, head] The updated Windows installer stuff

[Angus Leeming]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
> Angus> I'll apply the patches to 14x and to head now. I'll wait on
> Angus> JMarc's say so for the 13x patch.

> You can apply the 13x patch.

Ok, will do.

> I won't use for a 1.3.8 anyway,

Sorry, but that's bad grammar and I don't understand it. Are you trying to say
"I don't anticipate creating a 1.3.8 release"? If so, I appreciate that, but if
the worst happens and a 1.3.8 release is needed, then it'd be nice if it 'just
worked'.

> but it is useful to keep things in one place.
> Will you release a new 1.3.7 installer?

Dunno yet. It would be nice if someone knowledgable would tell me how to play
with the iconv-enabled gettext thingie...

I'd also have to play with the Aspell 0.6 stuff (download the dictionaries to
the expected place) unless someone else beats me to it and can confirm that the
spell checker is working.

Angus

Re: LyX/Win 1.4.0

[Angus Leeming]

Stephen Harris wrote:

Angus wrote:

I anticipate that the installer will have the same bugs as the 1.3.x 
version since the installer code is little different to the previous 
version. (The one real change being that I've removed all tests for Perl 
in the installer.)

--

The install completed quickly. The File/Import started with just the two 
options for lines. I ran sh configure in C:\Lyx140\Resouces as usual for 
me.. Reconfigure, and regained Latex as an import option.


I got an error message during the install: "Failed attempting to set
path_prefix in the configure script."


Hi, Stephen.

This problem with the path_prefix stuff should now be fixed. Perhaps you'd 
like to test it out?


http://wiki.lyx.org/uploads/Windows/LyX137/lyx-1.3.7_win32_setup_v4.exe
http://wiki.lyx.org/uploads/Windows/LyX140pre/lyx-1.4.0pre_win32_setup_v2.exe

I'm still mulling over what to do with aspell. If we go for aspell 0.6 then 
it looks like I'll have to supply the dictionaries too. Would make Kevin 
Atkinson happy :)


Angus

Re: DVI search.

[João Luis Meloni Assirati]

Em Qui 02 Mar 2006 18:40, Jose' Matos escreveu:

Oi José!

> On Thursday 02 March 2006 21:32, João Luis Meloni Assirati wrote:
>
> Olá João, :-)
>  (Oi seria melhor ? ;-)

Está bem das duas maneiras. Gosto do modo português de falar, também :)
(Lars, keep reading, please :)

> >
> > I don't get it. What is the problem?
>
> class TexRow {
> ...
> int TexRow::getRowFromId(int id, int pos) const;
> ...
> }
>
> The use of TexRow classifier inside the class is wrong, since the function
> is declared there. The right syntax is:
>
> class TexRow {
> ...
> int getRowFromId(int id, int pos) const;
> ...
> }

Sorry, guys. I hadn't reallized that Lars post  was about the .h file. I 
understand now, it was a stupid error. Attached is the updated patch.

Thanks,
João.
Index: src/BufferView.h
===
--- src/BufferView.h	(revision 13280)
+++ src/BufferView.h	(working copy)
@@ -179,6 +179,8 @@
 	int offset_ref() const;
 	/// access to anchor
 	lyx::pit_type anchor_ref() const;
+	/// access to the texrow corresponding to the beginning of the view
+	int texrow_ref() const;
 
 	/// access to full cursor
 	LCursor & cursor();
Index: src/BufferView.C
===
--- src/BufferView.C	(revision 13280)
+++ src/BufferView.C	(working copy)
@@ -387,6 +387,13 @@
 }
 
 
+int BufferView::texrow_ref() const 
+{
+	return buffer()->texrow().getRowFromId(
+		buffer()->paragraphs()[anchor_ref()].id(), offset_ref());
+}
+
+
 int BufferView::offset_ref() const
 {
 	return pimpl_->offset_ref_;
Index: src/LaTeX.C
===
--- src/LaTeX.C	(revision 13280)
+++ src/LaTeX.C	(working copy)
@@ -383,7 +383,10 @@
 
 int LaTeX::startscript()
 {
-	string tmp = cmd + ' ' + QuoteName(file) + " > " + os::nulldev();
+	string tmp = cmd;
+	if (runparams.srcspecials)
+		tmp += ' ' + lyxrc.source_specials_switch;
+	tmp += ' ' + QuoteName(file) + " > " + os::nulldev();
 	Systemcall one;
 	return one.startscript(Systemcall::Wait, tmp);
 }
Index: src/buffer.C
===
--- src/buffer.C	(revision 13280)
+++ src/buffer.C	(working copy)
@@ -1280,7 +1280,7 @@
 
 	switch (func.action) {
 		case LFUN_EXPORT: {
-			bool const tmp = Exporter::Export(this, func.argument, false);
+			bool const tmp = Exporter::Export(this, func.argument, false, false);
 			if (result)
 *result = tmp;
 			break;
Index: src/converter.h
===
--- src/converter.h	(revision 13280)
+++ src/converter.h	(working copy)
@@ -107,12 +107,13 @@
 	bool convert(Buffer const * buffer,
 		 std::string const & from_file, std::string const & to_file_base,
 		 std::string const & from_format, std::string const & to_format,
- std::string & to_file, bool try_default = false);
+		 std::string & to_file, bool try_default = false,
+		 bool for_preview = false);
 	///
 	bool convert(Buffer const * buffer,
 		 std::string const & from_file, std::string const & to_file_base,
 		 std::string const & from_format, std::string const & to_format,
- bool try_default = false);
+ bool try_default = false, bool for_preview = false);
 	///
 	void update(Formats const & formats);
 	///
Index: src/converter.C
===
--- src/converter.C	(revision 13280)
+++ src/converter.C	(working copy)
@@ -281,7 +281,8 @@
 bool Converters::convert(Buffer const * buffer,
 			 string const & from_file, string const & to_file_base,
 			 string const & from_format, string const & to_format,
-			 string & to_file, bool try_default)
+			 string & to_file, bool try_default,
+			 bool for_preview)
 {
 	string const to_ext = formats.extension(to_format);
 	to_file = ChangeExtension(to_file_base, to_ext);
@@ -323,6 +324,8 @@
 	}
 	OutputParams runparams;
 	runparams.flavor = getFlavor(edgepath);
+	runparams.srcspecials = (for_preview && to_format == "dvi");
+	runparams.latexfile = from_file;
 	string path = OnlyPath(from_file);
 	Path p(path);
 
@@ -515,11 +518,11 @@
 bool Converters::convert(Buffer const * buffer,
 			 string const & from_file, string const & to_file_base,
 			 string const & from_format, string const & to_format,
- bool try_default)
+ bool try_default, bool for_preview)
 {
 	string to_file;
 	return convert(buffer, from_file, to_file_base, from_format, to_format,
-		   to_file, try_default);
+		   to_file, try_default, for_preview);
 }
 
 
@@ -576,7 +579,7 @@
 	runparams.document_language = buffer.params().language->babel();
 
 	// do the LaTeX run(s)
-	string const name = buffer.getLatexName();
+	string const name = runparams.latexfile;
 	LaTeX latex(command, runparams, name, buffer.filePath());
 	TeXErrors terr;
 	showMessage show(buffer);

Re: LyX/Win 1.4.0

[Joost Verburg]

Angus Leeming wrote:
I'm still mulling over what to do with aspell. If we go for aspell 0.6 
then it looks like I'll have to supply the dictionaries too. Would make 
Kevin Atkinson happy :)


I just tested the new Aspell. Version 0.6 works fine and more recent 
dictionaries are available compared to 0.5, so I'd prefer the new one :)


These dictionaries do need to be compiled (it looks like it generates 
.rws files) since the only precompiled dictionaries available are 
totally outdated.


I compiled a few of them and it only seems to take a few seconds for 
each dictionary. So it should not be too difficult to compile them all, 
I guess a shell script could do the job (download, extract, make) 
automatically.


Joost

Re: LyX/Win 1.4.0

[Angus Leeming]

Joost Verburg <[EMAIL PROTECTED]> writes:
> Angus Leeming wrote:
> > I'm still mulling over what to do with aspell. If we go for aspell 0.6 
> > then it looks like I'll have to supply the dictionaries too. Would make 
> > Kevin Atkinson happy :)

> I just tested the new Aspell. Version 0.6 works fine and more recent 
> dictionaries are available compared to 0.5, so I'd prefer the new one :)

> These dictionaries do need to be compiled (it looks like it generates 
> .rws files) since the only precompiled dictionaries available are 
> totally outdated.

Hi, Joost.

can you confirm that the new flavours of LyX compiled with aspell 0.6 work too?

> I compiled a few of them and it only seems to take a few seconds for 
> each dictionary. So it should not be too difficult to compile them all, 
> I guess a shell script could do the job (download, extract, make) 
> automatically.

If you take on the task and mail Kevin so that he can make these things
available to the wider world, then you'll be doing us all a great service.

I see that these dictionaries are packaged up in an installer on Windows. Did
you try that out too?

Angus