Re: [PATCH] fix french language handling

[Yves Bastide]

Jean-Marc Lasgouttes wrote:

Yves == Yves Bastide [EMAIL PROTECTED] writes:


Yves Just one nit: add a comment to the latex_options, such as
Yves +french french French false iso8859-1 fr_FR
Yves 
\addto\extrasfrench{\providecommand{\og}{\leavevmode\flqq~}\providecommand{\fg}{\ifdim\lastskip[EMAIL
 PROTECTED]
Yves % Definitions of \og and \fg for older french language
Yves definitions

Unfortunately I cannot do that because the file lib/languages does not
allow lin breaks in fields (it would not be _so_ difficult to change,
but now is not the time for that). Therefore I added a comment in the
file itself, but it will not appear in the .tex file.


Uh, my line was broken by Mozilla Mail :)



Here is the patch I am going to commit.


Looks fine. I hope frenchle will be reuseable in the future...



JMarc


yves

Re: [PATCH] fix french language handling

[Yves Bastide]

Jean-Marc Lasgouttes wrote:

"Yves" == Yves Bastide <[EMAIL PROTECTED]> writes:


Yves> Just one nit: add a comment to the latex_options, such as
Yves> +french french "French" false iso8859-1 fr_FR
Yves> 
"\addto\extrasfrench{\providecommand{\og}{\leavevmode\flqq~}\providecommand{\fg}{\ifdim\lastskip>[EMAIL
 PROTECTED]
Yves> % Definitions of \og and \fg for older french language
Yves> definitions"

Unfortunately I cannot do that because the file lib/languages does not
allow lin breaks in fields (it would not be _so_ difficult to change,
but now is not the time for that). Therefore I added a comment in the
file itself, but it will not appear in the .tex file.


Uh, my line was broken by Mozilla Mail :)



Here is the patch I am going to commit.


Looks fine. I hope frenchle will be reuseable in the future...



JMarc


yves

Re: [PATCH] fix french language handling

[Yves Bastide]

Jean-Marc Lasgouttes wrote:


Yves,

I would be interested to have more input from you on this subject, so
that I can try to improve my patch and eventually commit it.


Sorry to answer so late. Your patch doesn't solve the main problem: how 
to use frenchle with a recent TeX distribution. But I don't see any 
reasonable way for it (that is, short of dubious symlinks, sed 
preprocessing, babel enhancement and such) so it may be the best option...


Just one nit: add a comment to the latex_options, such as
+french  french 	French	false  iso8859-1  fr_FR	 
\addto\extrasfrench{\providecommand{\og}{\leavevmode\flqq~}\providecommand{\fg}{\ifdim\lastskip[EMAIL PROTECTED] 
% Definitions of \og and \fg for older french language definitions




JMarc



yves

Re: [PATCH] fix french language handling

[Yves Bastide]

Jean-Marc Lasgouttes wrote:


Yves,

I would be interested to have more input from you on this subject, so
that I can try to improve my patch and eventually commit it.


Sorry to answer so late. Your patch doesn't solve the main problem: how 
to use frenchle with a recent TeX distribution. But I don't see any 
reasonable way for it (that is, short of dubious symlinks, sed 
preprocessing, babel enhancement and such) so it may be the best option...


Just one nit: add a comment to the latex_options, such as
+french  french 	"French"	false  iso8859-1  fr_FR	 
"\addto\extrasfrench{\providecommand{\og}{\leavevmode\flqq~}\providecommand{\fg}{\ifdim\lastskip>[EMAIL PROTECTED] 
% Definitions of \og and \fg for older french language definitions"




JMarc



yves

Re: [PATCH] fix french language handling

[Yves Bastide]

Jean-Marc Lasgouttes wrote:
[...]


This will not work because we pass the language as a documentclass
option and it is not possible to load two french languages, AFAIK.


It could work by not using babel:

\documentclass[french]{article}
.
.
.
\usepackage{frenchle}

But then, one cannot use other languages...



A solution may be to add the language to lib/language. I think most
users would not know what to do with two options.


The current name [Franch (GUTenberg)] is a poor choice. Nonetheless, I
think this would be the best option. Localized packages would then be
handled using preamble or ERT (quick grep in texmf: ntgclass/brife,
layout, and varioref).


The experience on
lyx-fr is that the only voice to reclaim to presence of frenchle/pro
is the voice of its author. Personally, I am not able to tell the
difference.


The output is different. For instance, until recently frenchb did not
typeout footnote marks correctly (and still doesn't by default); other
differences remain, and some people prefer frenchle's ways.



JMarc



yves

Re: [PATCH] fix french language handling

[Yves Bastide]

Jean-Marc Lasgouttes wrote:
[...]


This will not work because we pass the language as a documentclass
option and it is not possible to load two french languages, AFAIK.


It could work by not using babel:

\documentclass[french]{article}
.
.
.
\usepackage{frenchle}

But then, one cannot use other languages...



A solution may be to add the language to lib/language. I think most
users would not know what to do with two options.


The current name [Franch (GUTenberg)] is a poor choice. Nonetheless, I
think this would be the best option. Localized packages would then be
handled using preamble or ERT (quick grep in texmf: ntgclass/brife,
layout, and varioref).


The experience on
lyx-fr is that the only voice to reclaim to presence of frenchle/pro
is the voice of its author. Personally, I am not able to tell the
difference.


The output is different. For instance, until recently frenchb did not
typeout footnote marks correctly (and still doesn't by default); other
differences remain, and some people prefer frenchle's ways.



JMarc



yves

Re: pyhton questions + a new credits.php page of the web site?

[Yves Bastide]

(sorry I've broken the thread)

Angus Leeming wrote:
 I've written a python script (attached) to convert lib/CREDITS to a
 web page.

[...]

 Questions for our resident python gurus:

Being neither resident not a guru...

 * Is there a python iconv or recode module? It would be nice to do
 this in one step only.

Yep. There's also the unicode built-in type which accept many encodings as
input and output.

 * If not, then how do I modify the script to take its input from STDIN
 so I can use it as

 $ recode ISO-8859-1..H4  CREDITS | ./phpcredits.py  credits.php

By using sys.stdin


Here's a version of your script which reads the file directly (argv[1] or
stdin) and most importantly doesn't use regexps :-)

Regards,

yves
#!/usr/bin/env python

'''
A script that converts CREDITS to a php file

The CREDITS file consists of multiple contributer entries

for i = 1, n {
@bName
@iContact details
Description of contribution, possibly
spanning multiple lines
}

A final paragraph, separated from the list above by a blank line

This script converts this data to UTF-8 encoded HTML+PHP. The contributers
are formatted as a Descriptive List.

'''

import sys
import codecs

class Contributer(object):
def __init__(self, name, contact, description):
self.name = name
self.contact = contact
self.description = description


def xml_escape(s):
s = s.replace(, amp;)
s = s.replace(, lt;)
s = s.replace(]], ]]gt;)
return s


def as_descriptive_list_elem(contributer):
results = [dt]
results.append( b%s/b % xml_escape(contributer.name))
if contributer.contact:
results.append( i%s/i % xml_escape(contributer.contact))
results.append(/dt)
results.append(dd
 %s
/dd
 % xml_escape(contributer.description))
return \n.join(results)


def as_descriptive_list(contributers):
results = [dl]
for contributer in contributers:
elt = as_descriptive_list_elem(contributer)
elt = elt.replace(\n, \n )
results.append( %s % elt)
results.append(/dl)
return \n.join(results)


def as_paragraph(s):
s = s.replace(\n, \n )
s = xml_escape(s)
return p
 %s
/p % s

class Credits(object):
def __init__(self):
self.contributers = []
self.final = 

def read(self, credits_fd):
prev_line = None
while True:
if prev_line:
line = prev_line
prev_line = None
else:
line = credits_fd.readline()
line = line.strip()
if not line:
# Stop on first blank line
break
assert line.startswith(@b), line
name = line[2:].strip()
line = credits_fd.readline()
if line.startswith(@):
assert line.startswith(@i), line
contact = line[2:].strip()
if contact.startswith(E-mail:):
email = contact[7:].strip()
ename, address = email.split(@, 1)
address = address.replace(.,  ! )
contact = %s () %s % (ename, address)
description = []
else:
line = line.strip()
description = [line]
while True:
line = credits_fd.readline()
if not line.strip():
break
if line.startswith(@):
break
description.append(line.strip())
prev_line = line
description =  .join(description)
contributer = Contributer(name, contact, description)
self.contributers.append(contributer)

post = []
for line in credits_fd:
post.append(line)
self.final =  .join(post)

def __unicode__(self):
return u%s\n\n%s % (as_descriptive_list(self.contributers),
  as_paragraph(self.final))



header = u?php
// What's the title of the page?
$title = CREDITS;
// Who is the author?
$author=[EMAIL PROTECTED];
// Full name of this file (relative path from LyX home page)
$file_full=about/credits.php;

include(start.php3);
?


footer = u
?php
include(end.php3);
?


def main():
if len(sys.argv) == 2:
fd = codecs.open(sys.argv[1], rb, latin1)
else:
fd = codecs.EncodedFile(sys.stdin, latin1)

credits = Credits()
credits.read(fd)
print header.encode(utf-8)
print unicode(credits).encode(utf-8)
print footer.encode(utf-8)

if __name__ == __main__:
main()

Re: pyhton questions + a new credits.php page of the web site?

[Yves Bastide]

(sorry I've broken the thread)

Angus Leeming wrote:
> I've written a python script (attached) to convert lib/CREDITS to a
> web page.

[...]

> Questions for our resident python gurus:

Being neither resident not a guru...

> * Is there a python iconv or recode module? It would be nice to do
> this in one step only.

Yep. There's also the unicode built-in type which accept many encodings as
input and output.

> * If not, then how do I modify the script to take its input from STDIN
> so I can use it as
>
> $ recode ISO-8859-1..H4 < CREDITS | ./phpcredits.py > credits.php

By using sys.stdin


Here's a version of your script which reads the file directly (argv[1] or
stdin) and most importantly doesn't use regexps :-)

Regards,

yves
#!/usr/bin/env python

'''
A script that converts CREDITS to a php file

The CREDITS file consists of multiple contributer entries

for i = 1, n {
@bName
@iContact details
Description of contribution, possibly
spanning multiple lines
}

A final paragraph, separated from the list above by a blank line

This script converts this data to UTF-8 encoded HTML+PHP. The contributers
are formatted as a Descriptive List.

'''

import sys
import codecs

class Contributer(object):
def __init__(self, name, contact, description):
self.name = name
self.contact = contact
self.description = description


def xml_escape(s):
s = s.replace("&", "")
s = s.replace("<", "")
s = s.replace("]]>", "]]")
return s


def as_descriptive_list_elem(contributer):
results = [""]
results.append(" %s" % xml_escape(contributer.name))
if contributer.contact:
results.append(" %s" % xml_escape(contributer.contact))
results.append("")
results.append("""
 %s

""" % xml_escape(contributer.description))
return "\n".join(results)


def as_descriptive_list(contributers):
results = [""]
for contributer in contributers:
elt = as_descriptive_list_elem(contributer)
elt = elt.replace("\n", "\n ")
results.append(" %s" % elt)
results.append("")
return "\n".join(results)


def as_paragraph(s):
s = s.replace("\n", "\n ")
s = xml_escape(s)
return """
 %s
""" % s

class Credits(object):
def __init__(self):
self.contributers = []
self.final = ""

def read(self, credits_fd):
prev_line = None
while True:
if prev_line:
line = prev_line
prev_line = None
else:
line = credits_fd.readline()
line = line.strip()
if not line:
# Stop on first blank line
break
assert line.startswith("@b"), line
name = line[2:].strip()
line = credits_fd.readline()
if line.startswith("@"):
assert line.startswith("@i"), line
contact = line[2:].strip()
if contact.startswith("E-mail:"):
email = contact[7:].strip()
ename, address = email.split("@", 1)
address = address.replace(".", " ! ")
contact = "<%s () %s>" % (ename, address)
description = []
else:
line = line.strip()
description = [line]
while True:
line = credits_fd.readline()
if not line.strip():
break
if line.startswith("@"):
break
description.append(line.strip())
prev_line = line
description = " ".join(description)
contributer = Contributer(name, contact, description)
self.contributers.append(contributer)

post = []
for line in credits_fd:
post.append(line)
self.final = " ".join(post)

def __unicode__(self):
return u"%s\n\n%s" % (as_descriptive_list(self.contributers),
  as_paragraph(self.final))



header = u"""
"""

footer = u"""

"""

def main():
if len(sys.argv) == 2:
fd = codecs.open(sys.argv[1], "rb", "latin1")
else:
fd = codecs.EncodedFile(sys.stdin, "latin1")

credits = Credits()
credits.read(fd)
print header.encode("utf-8")
print unicode(credits).encode("utf-8")
print footer.encode("utf-8")

if __name__ == "__main__":
main()

Re: The LyX licence

[Yves Bastide]

Angus Leeming wrote:
[...]
 In light of all this, I'm asking whether I can have your permission to 
 add your names to http://www.lyx.org/blanket-permission.txt:
 
 The following people hereby grant permission to licence their 
 contributions to LyX under the Gnu General Public Licence, version 2 
 or later.
 
Of course; although I dunno whether any of my bugs are still present in LyX :-)

yves

Re: The LyX licence

[Yves Bastide]

Angus Leeming wrote:
[...]
> In light of all this, I'm asking whether I can have your permission to 
> add your names to http://www.lyx.org/blanket-permission.txt:
> 
> "The following people hereby grant permission to licence their 
> contributions to LyX under the Gnu General Public Licence, version 2 
> or later."
> 
Of course; although I dunno whether any of my bugs are still present in LyX :-)

yves

booktabs/tableaux support in 1.4.x ?

[Yves Bastide]

Kuba Ober wrote:

 Hi,

 Since some time I'm contemplating implementing booktabs a.k.a. tableaux
 support for 1.3.x. Would that have a chance to go in, if properly 
done? I.e.
 are any new features allowed into 1.3.x? I might have asked that 
before, but
 have forgotten the answer since :) *

 I'm thinking of adding a per-table Book-style table checkbox which 
will
 limit what you can do to the table - i.e. no vertical lines, as well as
 adding support for top/mid/bottom rule and cmidrule. Since this would 
rather
 trivially extend the file format keeping it 100% upward compatible, 
it needs
 a `cat`-style up-lyxconvert, and a reasonably trivial down-lyxconvert 
which
 I'm willing to write as well - I'm thinking it would simply downgrade 
the
 nice rules into obnoxious standard ones.

 Comments/rants/flames welcome.

 Cheers, Kuba Ober

 * and I'm too lazy to look for it in the archives. Maybe with some 
external
 coercion :)


Here's a limited patch for 1.4cvs.
It has several limitations:
* As Alfredo wrote, tables don't work currently in 1.4cvs, so they're a 
bit hard to test :)

* The UI patch is only for Qt, not XForms. And is pretty minimalist: a 
Booktabs check box in the table dialog. We'd need also a global 
preference -- not to mention renaming it.

* Likewise, I named the flag booktabs in the source (isBookTabs(), 
feature booktabs=true, etc.). I think a better name is needed here 
also (tableau?)

* Vertical bars are not disabled. Should they? And they're 
systematically removed at creation time (yay! ;-))

* The booktabs class is added as a feature, but the package's 
existence not checked.

* No doc patch.

Regards,

Yves

[I left the interesting part of the patch readable and gziped the 
src/frontends/qt2/ui/QTabularDialogBase.ui one]
Index: src/LaTeXFeatures.C
===
RCS file: /cvs/lyx/lyx-devel/src/LaTeXFeatures.C,v
retrieving revision 1.103
diff -u -p -r1.103 LaTeXFeatures.C
--- src/LaTeXFeatures.C 2004/01/21 17:52:05 1.103
+++ src/LaTeXFeatures.C 2004/01/29 16:54:32
@@ -191,7 +191,8 @@ char const * simplefeatures[] = {
wasy,
dvipost,
fancybox,
-   calc
+   calc,
+   booktabs
 };
 
 int const nb_simplefeatures = sizeof(simplefeatures) / sizeof(char const *);
Index: src/tabular.C
===
RCS file: /cvs/lyx/lyx-devel/src/tabular.C,v
retrieving revision 1.202
diff -u -p -r1.202 tabular.C
--- src/tabular.C   2004/01/26 10:13:09 1.202
+++ src/tabular.C   2004/01/29 16:54:34
@@ -303,9 +303,9 @@ LyXTabular::cellstruct::cellstruct(Buffe
multicolumn = LyXTabular::CELL_NORMAL;
alignment = LYX_ALIGN_CENTER;
valignment = LYX_VALIGN_TOP;
-   top_line = true;
+   top_line = false;
bottom_line = false;
-   left_line = true;
+   left_line = false;
right_line = false;
usebox = BOX_NONE;
rotate = false;
@@ -314,7 +314,7 @@ LyXTabular::cellstruct::cellstruct(Buffe
 
 LyXTabular::rowstruct::rowstruct()
 {
-   top_line = true;
+   top_line = false;
bottom_line = false;
ascent_of_row = 0;
descent_of_row = 0;
@@ -328,7 +328,7 @@ LyXTabular::rowstruct::rowstruct()
 
 LyXTabular::columnstruct::columnstruct()
 {
-   left_line = true;
+   left_line = false;
right_line = false;
alignment = LYX_ALIGN_CENTER;
valignment = LYX_VALIGN_TOP;
@@ -362,12 +362,11 @@ void LyXTabular::init(BufferParams const
column_info.reserve(10);
cell_info.reserve(100);
fixCellNums();
-   for (int i = 0; i  rows_; ++i)
-   cell_info[i].back().right_line = true;
row_info.back().bottom_line = true;
+   row_info.front().top_line = true;
row_info.front().bottom_line = true;
-   column_info.back().right_line = true;
is_long_tabular = false;
+   is_booktabs = false;
rotate = false;
 }
 
@@ -380,7 +379,6 @@ void LyXTabular::fixCellNums()
cell_info[i][j].inset.setDrawFrame(InsetText::LOCKED);
cell_info[i][j].cellno = cellno++;
}
-   cell_info[i].back().right_line = true;
}
 
set_row_column_number_info();
@@ -1087,6 +1085,7 @@ void LyXTabular::write(Buffer const  bu
// global longtable options
os  features
write_attribute(rotate, rotate)
+   write_attribute(booktabs, is_booktabs)
write_attribute(islongtable, is_long_tabular)
write_attribute(firstHeadTopDL, endfirsthead.topDL)
write_attribute(firstHeadBottomDL, endfirsthead.bottomDL)
@@ -1253,6 +1252,7 @@ void LyXTabular::read(Buffer const  buf
return;
}
getTokenValue(line, rotate, rotate);
+   getTokenValue(line, booktabs, is_booktabs);
getTokenValue(line, islongtable, is_long_tabular);
// 

booktabs/tableaux support in 1.4.x ?

[Yves Bastide]

Kuba Ober wrote:
>
> Hi,
>
> Since some time I'm contemplating implementing booktabs a.k.a. tableaux
> support for 1.3.x. Would that have a chance to go in, if properly 
done? I.e.
> are any new features allowed into 1.3.x? I might have asked that 
before, but
> have forgotten the answer since :) *
>
> I'm thinking of adding a per-table "Book-style table" checkbox which 
will
> limit what you can do to the table - i.e. no vertical lines, as well as
> adding support for top/mid/bottom rule and cmidrule. Since this would 
rather
> trivially extend the file format keeping it 100% upward compatible, 
it needs
> a `cat`-style up-lyxconvert, and a reasonably trivial down-lyxconvert 
which
> I'm willing to write as well - I'm thinking it would simply downgrade 
the
> "nice" rules into obnoxious "standard" ones.
>
> Comments/rants/flames welcome.
>
> Cheers, Kuba Ober
>
> * and I'm too lazy to look for it in the archives. Maybe with some 
external
> coercion :)
>

Here's a limited patch for 1.4cvs.
It has several limitations:
* As Alfredo wrote, tables don't work currently in 1.4cvs, so they're a 
bit hard to test :)

* The UI patch is only for Qt, not XForms. And is pretty minimalist: a 
"Booktabs" check box in the table dialog. We'd need also a global 
preference -- not to mention renaming it.

* Likewise, I named the flag "booktabs" in the source (isBookTabs(), 
, etc.). I think a better name is needed here 
also (tableau?)

* Vertical bars are not disabled. Should they? And they're 
systematically removed at creation time (yay! ;-))

* The "booktabs" class is added as a feature, but the package's 
existence not checked.

* No doc patch.

Regards,

Yves

[I left the "interesting" part of the patch readable and gziped the 
src/frontends/qt2/ui/QTabularDialogBase.ui one]
Index: src/LaTeXFeatures.C
===
RCS file: /cvs/lyx/lyx-devel/src/LaTeXFeatures.C,v
retrieving revision 1.103
diff -u -p -r1.103 LaTeXFeatures.C
--- src/LaTeXFeatures.C 2004/01/21 17:52:05 1.103
+++ src/LaTeXFeatures.C 2004/01/29 16:54:32
@@ -191,7 +191,8 @@ char const * simplefeatures[] = {
"wasy",
"dvipost",
"fancybox",
-   "calc"
+   "calc",
+   "booktabs"
 };
 
 int const nb_simplefeatures = sizeof(simplefeatures) / sizeof(char const *);
Index: src/tabular.C
===
RCS file: /cvs/lyx/lyx-devel/src/tabular.C,v
retrieving revision 1.202
diff -u -p -r1.202 tabular.C
--- src/tabular.C   2004/01/26 10:13:09 1.202
+++ src/tabular.C   2004/01/29 16:54:34
@@ -303,9 +303,9 @@ LyXTabular::cellstruct::cellstruct(Buffe
multicolumn = LyXTabular::CELL_NORMAL;
alignment = LYX_ALIGN_CENTER;
valignment = LYX_VALIGN_TOP;
-   top_line = true;
+   top_line = false;
bottom_line = false;
-   left_line = true;
+   left_line = false;
right_line = false;
usebox = BOX_NONE;
rotate = false;
@@ -314,7 +314,7 @@ LyXTabular::cellstruct::cellstruct(Buffe
 
 LyXTabular::rowstruct::rowstruct()
 {
-   top_line = true;
+   top_line = false;
bottom_line = false;
ascent_of_row = 0;
descent_of_row = 0;
@@ -328,7 +328,7 @@ LyXTabular::rowstruct::rowstruct()
 
 LyXTabular::columnstruct::columnstruct()
 {
-   left_line = true;
+   left_line = false;
right_line = false;
alignment = LYX_ALIGN_CENTER;
valignment = LYX_VALIGN_TOP;
@@ -362,12 +362,11 @@ void LyXTabular::init(BufferParams const
column_info.reserve(10);
cell_info.reserve(100);
fixCellNums();
-   for (int i = 0; i < rows_; ++i)
-   cell_info[i].back().right_line = true;
row_info.back().bottom_line = true;
+   row_info.front().top_line = true;
row_info.front().bottom_line = true;
-   column_info.back().right_line = true;
is_long_tabular = false;
+   is_booktabs = false;
rotate = false;
 }
 
@@ -380,7 +379,6 @@ void LyXTabular::fixCellNums()
cell_info[i][j].inset.setDrawFrame(InsetText::LOCKED);
cell_info[i][j].cellno = cellno++;
}
-   cell_info[i].back().right_line = true;
}
 
set_row_column_number_info();
@@ -1087,6 +1085,7 @@ void LyXTabular::write(Buffer const & bu
// global longtable options
os << "

Re: mathed AMS fonts

[Yves Bastide]

Maybe something to document:  (some versions of?) XSetFontPath don't like
(some version of?) nfs mounted directories...

chellas:~/build/lyx-devel/lib% xset fp+ `pwd`/fonts
xset:  bad font path element (#38), possible causes are:
Directory does not exist or has wrong permissions
Directory missing fonts.dir
Incorrect font server address or syntax

chellas:/tmp% xset fp+ `pwd`/fonts
chellas:/tmp%

(my home directory is accessed via nfs, unlike of course /tmp)


Cheers,

Yves

Re: mathed AMS fonts

[Yves Bastide]

On Wed, Feb 06, 2002 at 03:58:23PM +, Jules Bean wrote:
 On Wed, Feb 06, 2002 at 04:54:51PM +0100, Yves Bastide wrote:
  Maybe something to document:  (some versions of?) XSetFontPath don't like
  (some version of?) nfs mounted directories...
  
  chellas:~/build/lyx-devel/lib% xset fp+ `pwd`/fonts
  xset:  bad font path element (#38), possible causes are:
  Directory does not exist or has wrong permissions
  Directory missing fonts.dir
  Incorrect font server address or syntax
  
  chellas:/tmp% xset fp+ `pwd`/fonts
  chellas:/tmp%
  
  (my home directory is accessed via nfs, unlike of course /tmp)
 
 Are you sure it isn't permissions?

Shh.  You're right, of course (hint for myself: next time, believe the
error messages :)

So it should be documented that permissions must be set right.  I thought
the server accessed the font directories as root (X's uid), it's not the
case...

 
 Jules

Yves

Re: mathed AMS fonts

[Yves Bastide]

Maybe something to document:  (some versions of?) XSetFontPath don't like
(some version of?) nfs mounted directories...

chellas:~/build/lyx-devel/lib% xset fp+ `pwd`/fonts
xset:  bad font path element (#38), possible causes are:
Directory does not exist or has wrong permissions
Directory missing fonts.dir
Incorrect font server address or syntax

chellas:/tmp% xset fp+ `pwd`/fonts
chellas:/tmp%

(my home directory is accessed via nfs, unlike of course /tmp)


Cheers,

Yves

Re: mathed AMS fonts

[Yves Bastide]

On Wed, Feb 06, 2002 at 03:58:23PM +, Jules Bean wrote:
> On Wed, Feb 06, 2002 at 04:54:51PM +0100, Yves Bastide wrote:
> > Maybe something to document:  (some versions of?) XSetFontPath don't like
> > (some version of?) nfs mounted directories...
> > 
> > chellas:~/build/lyx-devel/lib% xset fp+ `pwd`/fonts
> > xset:  bad font path element (#38), possible causes are:
> > Directory does not exist or has wrong permissions
> > Directory missing fonts.dir
> > Incorrect font server address or syntax
> > 
> > chellas:/tmp% xset fp+ `pwd`/fonts
> > chellas:/tmp%
> > 
> > (my home directory is accessed via nfs, unlike of course /tmp)
> 
> Are you sure it isn't permissions?

Shh.  You're right, of course (hint for myself: next time, believe the
error messages :)

So it should be documented that permissions must be set right.  I thought
the server accessed the font directories as root (X's uid), it's not the
case...

> 
> Jules

Yves

Re: config/lyxinclude.m4

[Yves Bastide]

On Fri, Oct 19, 2001 at 02:52:14PM +0200, Jean-Marc Lasgouttes wrote:
 
 I have fixed the configure stuff to work with autoconf 2.52 and
 automake 1.5. Can you confirm that it works?

Not at this time, sorry: I've just moved, leaving my computer 600 km back..

 
 JMarc

-- 
Yves Bastide
IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France
Standard: +33 (0) 2 99 84 71 00, Fax: +33 (0) 2 99 84 71 71

Re: config/lyxinclude.m4

[Yves Bastide]

On Fri, Oct 19, 2001 at 03:50:33PM +0200, Jean-Marc Lasgouttes wrote:
  Yves == Yves Bastide [EMAIL PROTECTED] writes:
 
 Yves Not at this time, sorry: I've just moved, leaving my computer
 Yves 600 km back..
 
 And you arms are to short to get to the keyboard?

Of course not.  The power cord is.

 
 JMarc

-- 
Yves Bastide
IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France
Standard: +33 (0) 2 99 84 71 00, Fax: +33 (0) 2 99 84 71 71

Re: config/lyxinclude.m4

[Yves Bastide]

On Fri, Oct 19, 2001 at 02:52:14PM +0200, Jean-Marc Lasgouttes wrote:
> 
> I have fixed the configure stuff to work with autoconf 2.52 and
> automake 1.5. Can you confirm that it works?

Not at this time, sorry: I've just moved, leaving my computer 600 km back..

> 
> JMarc

-- 
Yves Bastide
IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France
Standard: +33 (0) 2 99 84 71 00, Fax: +33 (0) 2 99 84 71 71

Re: config/lyxinclude.m4

[Yves Bastide]

On Fri, Oct 19, 2001 at 03:50:33PM +0200, Jean-Marc Lasgouttes wrote:
> >>>>> "Yves" == Yves Bastide <[EMAIL PROTECTED]> writes:
> 
> Yves> Not at this time, sorry: I've just moved, leaving my computer
> Yves> 600 km back..
> 
> And you arms are to short to get to the keyboard?

Of course not.  The power cord is.

> 
> JMarc

-- 
Yves Bastide
IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France
Standard: +33 (0) 2 99 84 71 00, Fax: +33 (0) 2 99 84 71 71

config/lyxinclude.m4

[Yves Bastide]

Does config/lyxinclude.m4 still need to use LYX_PROG_CXX instead of AC_*
(other than that LYX_* deals with --enable-warnings and others)?

The reason being that this macro doesn't work anymore with automake 1.5,
which uses a new dependency tracking implementation (which needs an
AC_SUBST done by AC_PROG_CXX).

Quick fix:

Index: config/lyxinclude.m4
===
RCS file: /cvs/lyx/lyx-devel/config/lyxinclude.m4,v
retrieving revision 1.46
diff -u -p -r1.46 lyxinclude.m4
--- config/lyxinclude.m42001/09/11 13:13:02 1.46
+++ config/lyxinclude.m42001/10/01 14:46:51
@@ -161,20 +161,7 @@ cross_compiling=$ac_cv_prog_cxx_cross
 
 AC_DEFUN(LYX_PROG_CXX,
 [AC_BEFORE([$0], [AC_PROG_CXXCPP])dnl
-AC_MSG_CHECKING([for a working C++ compiler])
-LYX_SEARCH_PROG(CXX, $CCC g++ gcc c++ CC cxx xlC cc++, LYX_PROG_CXX_WORKS)
-
-if test -z $CXX ; then
-  AC_ERROR([Unable to find a working C++ compiler])
-fi
-
-AC_SUBST(CXX)
-AC_MSG_RESULT($CXX)
-
-AC_MSG_CHECKING([whether the C++ compiler ($CXX $CXXFLAGS $LDFLAGS) is a
cross-
compiler])
-AC_MSG_RESULT($cross_compiling)
-
-AC_PROG_CXX_GNU
+AC_PROG_CXX
 
 ### We might want to get or shut warnings.
 AC_ARG_ENABLE(warnings,

-- cut --

Better one, I think: split LYX_PROG_CXX

Comments?

-- 
Yves

src/frontends/qt2/*/Makefile.am

[Yves Bastide]

src/frontends/qt2/{,ui/}Makefile.am define twice DISTCLEANFILES, the first
one seeming unnecessary.

Also, src/frontends/qt2/ui/moc/Makefile.am contains a strange
#$(patsubst, %, %Dialog_moc.C, $(DIALOGS))
line

(no harm done anyway)

-- 
Yves

Re: config/lyxinclude.m4

[Yves Bastide]

On Mon, Oct 01, 2001 at 05:39:38PM +0200, Jean-Marc Lasgouttes wrote:
  Yves == Yves Bastide [EMAIL PROTECTED] writes:
 
 Yves Does config/lyxinclude.m4 still need to use LYX_PROG_CXX instead
 Yves of AC_* (other than that LYX_* deals with --enable-warnings and
 Yves others)?
 
 Something nice that LYX_PROG_CXX is to search for a compiler that
 makes LYX_PROG_CXX_WORKS succeed. The later currently checks that the
 compiler supports namespace and mutable keywords.

True.  And nice indeed (now I know the reason for LYX_PROG_CXX :)

 
 Is something like that possible with AC_PROG_CXX?

I don't know... It may, but without going into its guts?..

 
 Yves The reason being that this macro doesn't work anymore with
 Yves automake 1.5, which uses a new dependency tracking
 Yves implementation (which needs an AC_SUBST done by AC_PROG_CXX).
 
 What AC_SUBST is that? We could provide it.

I don't even know if it's really an AC_SUBST, it just looked like after a
cursory glance (I've yet to find where is is).  Furthermore it's more than
that: searching for the type of dependency tracking possible with the
compiler used.

 
 Yves Better one, I think: split LYX_PROG_CXX
 
 It may be possible, but will not directly solve our problem.

Right, if the problem is finding which of the many compiler available have
two particular features.  BTW, why aren't the other ones (explicit, std::,
etc.) searched at the same time?

 
 JMarc

-- 
Yves

config/lyxinclude.m4

[Yves Bastide]

Does config/lyxinclude.m4 still need to use LYX_PROG_CXX instead of AC_*
(other than that LYX_* deals with --enable-warnings and others)?

The reason being that this macro doesn't work anymore with automake 1.5,
which uses a new dependency tracking implementation (which needs an
AC_SUBST done by AC_PROG_CXX).

Quick fix:

Index: config/lyxinclude.m4
===
RCS file: /cvs/lyx/lyx-devel/config/lyxinclude.m4,v
retrieving revision 1.46
diff -u -p -r1.46 lyxinclude.m4
--- config/lyxinclude.m42001/09/11 13:13:02 1.46
+++ config/lyxinclude.m42001/10/01 14:46:51
@@ -161,20 +161,7 @@ cross_compiling=$ac_cv_prog_cxx_cross
 
 AC_DEFUN(LYX_PROG_CXX,
 [AC_BEFORE([$0], [AC_PROG_CXXCPP])dnl
-AC_MSG_CHECKING([for a working C++ compiler])
-LYX_SEARCH_PROG(CXX, $CCC g++ gcc c++ CC cxx xlC cc++, LYX_PROG_CXX_WORKS)
-
-if test -z "$CXX" ; then
-  AC_ERROR([Unable to find a working C++ compiler])
-fi
-
-AC_SUBST(CXX)
-AC_MSG_RESULT($CXX)
-
-AC_MSG_CHECKING([whether the C++ compiler ($CXX $CXXFLAGS $LDFLAGS) is a
cross-
compiler])
-AC_MSG_RESULT($cross_compiling)
-
-AC_PROG_CXX_GNU
+AC_PROG_CXX
 
 ### We might want to get or shut warnings.
 AC_ARG_ENABLE(warnings,

<-- cut --

Better one, I think: split LYX_PROG_CXX

Comments?

-- 
Yves

src/frontends/qt2/*/Makefile.am

[Yves Bastide]

src/frontends/qt2/{,ui/}Makefile.am define twice DISTCLEANFILES, the first
one seeming unnecessary.

Also, src/frontends/qt2/ui/moc/Makefile.am contains a strange
#$(patsubst, %, %Dialog_moc.C, $(DIALOGS))
line

(no harm done anyway)

-- 
Yves

Re: config/lyxinclude.m4

[Yves Bastide]

On Mon, Oct 01, 2001 at 05:39:38PM +0200, Jean-Marc Lasgouttes wrote:
> >>>>> "Yves" == Yves Bastide <[EMAIL PROTECTED]> writes:
> 
> Yves> Does config/lyxinclude.m4 still need to use LYX_PROG_CXX instead
> Yves> of AC_* (other than that LYX_* deals with --enable-warnings and
> Yves> others)?
> 
> Something nice that LYX_PROG_CXX is to search for a compiler that
> makes LYX_PROG_CXX_WORKS succeed. The later currently checks that the
> compiler supports namespace and mutable keywords.

True.  And nice indeed (now I know the reason for LYX_PROG_CXX :)

> 
> Is something like that possible with AC_PROG_CXX?

I don't know... It may, but without going into its guts?..

> 
> Yves> The reason being that this macro doesn't work anymore with
> Yves> automake 1.5, which uses a new dependency tracking
> Yves> implementation (which needs an AC_SUBST done by AC_PROG_CXX).
> 
> What AC_SUBST is that? We could provide it.

I don't even know if it's really an AC_SUBST, it just looked like after a
cursory glance (I've yet to find where is is).  Furthermore it's more than
that: searching for the type of dependency tracking possible with the
compiler used.

> 
> Yves> Better one, I think: split LYX_PROG_CXX
> 
> It may be possible, but will not directly solve our problem.

Right, if the problem is finding which of the many compiler available have
two particular features.  BTW, why aren't the other ones (explicit, std::,
etc.) searched at the same time?

> 
> JMarc

-- 
Yves

Re: Feature request: latin9 support

[Yves Bastide]

On Fri, Sep 14, 2001 at 12:40:24PM +0200, Jean-Marc Lasgouttes wrote:
  Philipp == Philipp Lehman [EMAIL PROTECTED] writes:
 
 Philipp There is a latin9.def at
 Philipp http://www.loria.fr/~gustedt/iso8859-15.html which allows one
 Philipp to use iso8859-15 screen fonts and simply go
 Philipp \usepackage[latin9]{inputenc}. It works fine.
 
 Philipp I noticed that Lyx doesn't offer support for latin9. Since
 Philipp latin9 a.k.a iso8859-15 includes the euro sign as well as OE
 Philipp and oe ligatures, it comes in handy for a lot of European
 Philipp users. Please consider supporting it in the next release.
 
 It is already supported in 1.2.0cvs. However, the fact that latex does
 not support it (why??) is annoying (we cannot set it as default
 encoding for french, for example).

OTOH, it's just a 8 lines-patch to latin1; so it could maybe be included
in the preamble...
(a friday's suggestion)

 
 JMarc

-- 
Yves

Re: Feature request: latin9 support

[Yves Bastide]

On Fri, Sep 14, 2001 at 12:40:24PM +0200, Jean-Marc Lasgouttes wrote:
> > "Philipp" == Philipp Lehman <[EMAIL PROTECTED]> writes:
> 
> Philipp> There is a latin9.def at
> Philipp> http://www.loria.fr/~gustedt/iso8859-15.html which allows one
> Philipp> to use iso8859-15 screen fonts and simply go
> Philipp> \usepackage[latin9]{inputenc}. It works fine.
> 
> Philipp> I noticed that Lyx doesn't offer support for latin9. Since
> Philipp> latin9 a.k.a iso8859-15 includes the euro sign as well as OE
> Philipp> and oe ligatures, it comes in handy for a lot of European
> Philipp> users. Please consider supporting it in the next release.
> 
> It is already supported in 1.2.0cvs. However, the fact that latex does
> not support it (why??) is annoying (we cannot set it as default
> encoding for french, for example).

OTOH, it's just a 8 lines-patch to latin1; so it could maybe be included
in the preamble...
(a friday's suggestion)

> 
> JMarc

-- 
Yves

Re: PATCH: FreeBSD wchar (was: Free BSD fix to CVS)

[Yves Bastide]

On Wed, Sep 05, 2001 at 10:26:04AM +0900, R. Lahaye wrote:
 From: Yves Bastide wrote:
  Rob, what about my objection to putting this wchar.h in cheader?
 
 Well, this is all about getting CVS compiled on my FreeBSD PC.
 Your first patch, a day or two ago, didn't work for me. limits.cpp
 still included /usr/include/g++/cwchar, which is a C++ wrap that
 only does #include wchar.h. I decided to intervene this latter include,
 and put wchar.h in cheaders.
 You can object that, but what else do you suggest?

OK, I didn't know it didn't work.
This is really a bug in gcc plus one in boost.  Could you do as currently,
but putting wchar.h in cheaders/something (and adjust configure.in as
needed)?

 
 Rob.

-- 
Yves

Re: PATCH: FreeBSD wchar (was: Free BSD fix to CVS)

[Yves Bastide]

On Wed, Sep 05, 2001 at 02:30:13PM +0200, Jean-Marc Lasgouttes wrote:
 I would rather have a fix in boost (conditionally define
 BOOST_NO_LIMITS in boost/config.hpp for freebsd under the relevant gcc
 versions) that we could forward to them and have right now in our
 sources. This is IMO cleaner than using cheaders/.

Fully agreed, except that it should not depend on BOOST_NO_LIMITS
Perhaps patch details/limits.hpp to not include cwchar if
BOOST_NO_INTRINSIC_WCHAR_T is defined, then define this?

 
 JMarc

-- 
Yves

Re: PATCH: FreeBSD wchar (was: Free BSD fix to CVS)

[Yves Bastide]

On Wed, Sep 05, 2001 at 10:26:04AM +0900, R. Lahaye wrote:
> From: Yves Bastide wrote:
> > Rob, what about my objection to putting this wchar.h in cheader?
> 
> Well, this is all about getting CVS compiled on my FreeBSD PC.
> Your first patch, a day or two ago, didn't work for me. limits.cpp
> still included "/usr/include/g++/cwchar", which is a C++ wrap that
> only does "#include wchar.h". I decided to intervene this latter include,
> and put wchar.h in cheaders.
> You can object that, but what else do you suggest?

OK, I didn't know it didn't work.
This is really a bug in gcc plus one in boost.  Could you do as currently,
but putting wchar.h in cheaders/ (and adjust configure.in as
needed)?

> 
> Rob.

-- 
Yves

Re: PATCH: FreeBSD wchar (was: Free BSD fix to CVS)

[Yves Bastide]

On Wed, Sep 05, 2001 at 02:30:13PM +0200, Jean-Marc Lasgouttes wrote:
> I would rather have a fix in boost (conditionally define
> BOOST_NO_LIMITS in boost/config.hpp for freebsd under the relevant gcc
> versions) that we could forward to them and have right now in our
> sources. This is IMO cleaner than using cheaders/.

Fully agreed, except that it should not depend on BOOST_NO_LIMITS
Perhaps patch details/limits.hpp to not include  if
BOOST_NO_INTRINSIC_WCHAR_T is defined, then define this?

> 
> JMarc

-- 
Yves

Re: PATCH: FreeBSD wchar (was: Free BSD fix to CVS)

[Yves Bastide]

On Tue, Sep 04, 2001 at 10:01:21AM +0900, R. Lahaye wrote:
 
 Hi,
 
 The following patches work for FreeBSD 4.3 (latest official release),
 where C headers for wide char are not available.
 It's for present (and possibly older) versions of FreeBSD. New releases
 may probably ship with sufficient wide char support in the future.
 
 
 Here are the patches (also attached as gzipped diff-file, without the
 new wchar.h file):
[snip]

You puth wchar.h in cheader, and include this directory; the problem is
that all cheader/ files will then be used, not just wchar.h.  That's why my
proposed patch used a subdirectory.

Regards,
-- 
Yves

Re: reLyX bug

[Yves Bastide]

On Tue, Sep 04, 2001 at 02:22:56PM +0100, Jose Abilio Oliveira Matos wrote:
   
   As a curiosity, did reLyX worked before?
   I guess that if it work then we had a strange case of interaction beetween
 BLOCK and the variable outside. Hardly what anyone would expect.

BEGIN blocks are executed immediately after compilation.  Variable names
are known, but assignments in my constructs haven't been done yet.

With the previous version of reLyX, try
$ perl -w reLyX-1.2 
you'll get
Use of uninitialized value in concatenation (.) or string at
/usr/local/bin/reLyX-1.2 line 52.
Use of uninitialized value in concatenation (.) or string at
/usr/local/bin/reLyX-1.2 line 52.
Use of uninitialized value in concatenation (.) or string at
/usr/local/bin/reLyX-1.2 line 52.
Use of uninitialized value in concatenation (.) or string at
/usr/local/bin/reLyX-1.2 line 52.

the uninitialized value being $mainscript...

BTW (Amir I guess?) why 
#!/usr/bin/perl
then
$^W = 1; # same as 'perl -w'

?  This disables -w in the BEGIN {}, as seen here

[snip]

 
 -- 
 José

-- 
Yves

Re: PATCH: FreeBSD wchar (was: Free BSD fix to CVS)

[Yves Bastide]

On Tue, Sep 04, 2001 at 05:27:18PM +0200, Jean-Marc Lasgouttes wrote:
  R == R Lahaye [EMAIL PROTECTED] writes:
 
 R The following patches work for FreeBSD 4.3 (latest official
 R release), where C headers for wide char are not available. It's for
 R present (and possibly older) versions of FreeBSD. New releases may
 R probably ship with sufficient wide char support in the future.
 
 Could you describe what the exact problem is? Who wants to use
 wchar.h?

boost/limits.hpp, which is included by boost/crc.hpp (smiley appropriate :)

 
 JMarc

-- 
Yves

Re: PATCH: FreeBSD wchar (was: Free BSD fix to CVS)

[Yves Bastide]

On Tue, Sep 04, 2001 at 05:54:53PM +0200, Jean-Marc Lasgouttes wrote:
  R == R Lahaye [EMAIL PROTECTED] writes:
 
   Could you describe what the exact problem is? Who wants to use
  wchar.h?
 
 R Uh? boost/boost/detail/limits.h wants. Well, it includes cwchar,
 R which on my FreeBSD machine is a c++-wrapper to wchar.h. The
 R cwchar C++ wrapper exists on FreeBSD, but the wchar.h is missing.
 R As result, the make ends with an error message.
 
 I see. For my defense, I'll say that I did not read _all_ the 1200
 messages which were waiting for me in lyx-devel alone...

You mean: not yet ? :)

 
 R You could call that a FreeBSD bug, but that's the way this OS is
 R layed out up to version 4.3. From 5.0 onwards this might be solved.
 R But for the present releases, the patch I've sent in, makes CVS
 R compile on the existing official releases of FreeBSD (or any other
 R system that fails to wrap wchar.h).
 
 So the right fix would be to boost, in fact. The problem will not
 happen only with LyX. I guess the right fix is to add a check for
 freebsd in boost/config.hpp. Unfortunately, our local boost specialist
 is lars... 

Well, when lyx becomes multibytes, there will be problems with this issue
again..

 
 R Does that explain enough? I'm not expert enough to give deeper info
 R on that. I just wanted CVS compiled on my FreeBSD box.
 
 I see what you mean. I am also unable to compile with compaq cxx now
 that boost has been updated :)

The tie problem, or something else?

 
 JMarc

-- 
Yves

Re: PATCH: FreeBSD wchar (was: Free BSD fix to CVS)

[Yves Bastide]

On Tue, Sep 04, 2001 at 06:40:57PM +0200, Jean-Marc Lasgouttes wrote:
  Yves == Yves Bastide [EMAIL PROTECTED] writes:
 
 Yves Well, when lyx becomes multibytes, there will be problems with
 Yves this issue again..
 
 If FreeBSD does not have a wchar.h, I do not see how we can fix it anyway.

wchar_t being a type, I'd guess g++ can work around this

 
 
 R Does that explain enough? I'm not expert enough to give deeper info
 R on that. I just wanted CVS compiled on my FreeBSD box.
   I see what you mean. I am also unable to compile with compaq cxx
  now that boost has been updated :)
 
 Yves The tie problem, or something else?
 
 The BOOST_STATIC_CONSTANT macro. It has been fixed in the past, but
 Lars did not propagate the fix, it seems. I'll have to take a look to
 'cvs diff'.

shouldn't boost's configure take care of this?
(defining BOOST_NO_INCLASS_MEMBER_INITIALIZATION or so?)

 
 JMarc

-- 
Yves

Re: PATCH: FreeBSD wchar (was: Free BSD fix to CVS)

[Yves Bastide]

On Tue, Sep 04, 2001 at 10:01:21AM +0900, R. Lahaye wrote:
> 
> Hi,
> 
> The following patches work for FreeBSD 4.3 (latest official release),
> where C headers for wide char are not available.
> It's for present (and possibly older) versions of FreeBSD. New releases
> may probably ship with sufficient wide char support in the future.
> 
> 
> Here are the patches (also attached as gzipped diff-file, without the
> new wchar.h file):
[snip]

You puth wchar.h in cheader, and include this directory; the problem is
that all cheader/ files will then be used, not just wchar.h.  That's why my
proposed patch used a subdirectory.

Regards,
-- 
Yves

Re: reLyX bug

[Yves Bastide]

On Tue, Sep 04, 2001 at 02:22:56PM +0100, Jose Abilio Oliveira Matos wrote:
>   
>   As a curiosity, did reLyX worked before?
>   I guess that if it work then we had a strange case of interaction beetween
> BLOCK and the variable outside. Hardly what anyone would expect.

BEGIN blocks are executed immediately after compilation.  Variable names
are known, but assignments in "my" constructs haven't been done yet.

With the previous version of reLyX, try
$ perl -w reLyX-1.2 
you'll get
Use of uninitialized value in concatenation (.) or string at
/usr/local/bin/reLyX-1.2 line 52.
Use of uninitialized value in concatenation (.) or string at
/usr/local/bin/reLyX-1.2 line 52.
Use of uninitialized value in concatenation (.) or string at
/usr/local/bin/reLyX-1.2 line 52.
Use of uninitialized value in concatenation (.) or string at
/usr/local/bin/reLyX-1.2 line 52.

the uninitialized value being $mainscript...

BTW (Amir I guess?) why 
#!/usr/bin/perl
then
$^W = 1; # same as 'perl -w'

?  This disables -w in the BEGIN {}, as seen here

[snip]

> 
> -- 
> José

-- 
Yves

Re: PATCH: FreeBSD wchar (was: Free BSD fix to CVS)

[Yves Bastide]

On Tue, Sep 04, 2001 at 05:27:18PM +0200, Jean-Marc Lasgouttes wrote:
> > "R" == R Lahaye <[EMAIL PROTECTED]> writes:
> 
> R> The following patches work for FreeBSD 4.3 (latest official
> R> release), where C headers for wide char are not available. It's for
> R> present (and possibly older) versions of FreeBSD. New releases may
> R> probably ship with sufficient wide char support in the future.
> 
> Could you describe what the exact problem is? Who wants to use
> wchar.h?

boost/limits.hpp, which is included by boost/crc.hpp (smiley appropriate :)

> 
> JMarc

-- 
Yves

Re: PATCH: FreeBSD wchar (was: Free BSD fix to CVS)

[Yves Bastide]

On Tue, Sep 04, 2001 at 05:54:53PM +0200, Jean-Marc Lasgouttes wrote:
> > "R" == R Lahaye <[EMAIL PROTECTED]> writes:
> 
> >>  Could you describe what the exact problem is? Who wants to use
> >> wchar.h?
> 
> R> Uh? boost/boost/detail/limits.h wants. Well, it includes ,
> R> which on my FreeBSD machine is a c++-wrapper to . The
> R>  C++ wrapper exists on FreeBSD, but the wchar.h is missing.
> R> As result, the make ends with an error message.
> 
> I see. For my defense, I'll say that I did not read _all_ the 1200
> messages which were waiting for me in lyx-devel alone...

You mean: not yet ? :)

> 
> R> You could call that a FreeBSD bug, but that's the way this OS is
> R> layed out up to version 4.3. From 5.0 onwards this might be solved.
> R> But for the present releases, the patch I've sent in, makes CVS
> R> compile on the existing official releases of FreeBSD (or any other
> R> system that fails to wrap wchar.h).
> 
> So the right fix would be to boost, in fact. The problem will not
> happen only with LyX. I guess the right fix is to add a check for
> freebsd in boost/config.hpp. Unfortunately, our local boost specialist
> is lars... 

Well, when lyx becomes multibytes, there will be problems with this issue
again..

> 
> R> Does that explain enough? I'm not expert enough to give deeper info
> R> on that. I just wanted CVS compiled on my FreeBSD box.
> 
> I see what you mean. I am also unable to compile with compaq cxx now
> that boost has been updated :)

The tie<> problem, or something else?

> 
> JMarc

-- 
Yves

Re: PATCH: FreeBSD wchar (was: Free BSD fix to CVS)

[Yves Bastide]

On Tue, Sep 04, 2001 at 06:40:57PM +0200, Jean-Marc Lasgouttes wrote:
> >>>>> "Yves" == Yves Bastide <[EMAIL PROTECTED]> writes:
> 
> Yves> Well, when lyx becomes multibytes, there will be problems with
> Yves> this issue again..
> 
> If FreeBSD does not have a wchar.h, I do not see how we can fix it anyway.

wchar_t being a type, I'd guess g++ can work around this

> 
> >>
> R> Does that explain enough? I'm not expert enough to give deeper info
> R> on that. I just wanted CVS compiled on my FreeBSD box.
> >>  I see what you mean. I am also unable to compile with compaq cxx
> >> now that boost has been updated :)
> 
> Yves> The tie<> problem, or something else?
> 
> The BOOST_STATIC_CONSTANT macro. It has been fixed in the past, but
> Lars did not propagate the fix, it seems. I'll have to take a look to
> 'cvs diff'.

shouldn't boost's configure take care of this?
(defining BOOST_NO_INCLASS_MEMBER_INITIALIZATION or so?)

> 
> JMarc

-- 
Yves

Re: Bug list - Update No. 73251

[Yves Bastide]

On Mon, Sep 03, 2001 at 01:24:13PM +0200, Herbert Voss wrote:
 Michael Schmitt wrote:
  
  On Mon, 3 Sep 2001, Herbert Voss wrote:
  
   this is your problem, not a latex one ...
   when you add your margin note _direct_ before the last word,
   than the parbox of the margin and the word are a unit(!) and
   hyphenation is not possible!
   a margin should always appear as a word, means space before
   _and_ space behind, than all works well.
  
  Aha! May I draw the conclusion that LyX should add a space before and
  after each margin note automatically when exporting to LaTeX?
 
 I was too quick with my answer. It may be a problem of hyphenation,
 because
  
 \tolerance=200
 \setlength{\emergencystretch}{2em}
 
 solve the problem ...
 
 I'll have a closer look at it.

Is such fiddling appropriate, when all we have is a user bug ? :-)
A marginpar, like a footnote or an index entry, is meant to refer to the
preceding word.  No?

 
 Herbert
 
 
 -- 
 http://www.educat.hu-berlin.de/~voss/lyx/

-- 
Yves

Re: Bug list - Update No. 73251

[Yves Bastide]

On Mon, Sep 03, 2001 at 02:38:00PM +0200, Herbert Voss wrote:
 Yves Bastide wrote:
  
  Is such fiddling appropriate, when all we have is a user bug ? :-)
  A marginpar, like a footnote or an index entry, is meant to refer to the
  preceding word.  No?
 
 no, as far as i know to the line of the \marginpar command.
 but it always works when it is near to the preceeding
 word, because there are no problems with hyphenation.

You're right; still, I would put it either after the significant word, at
the end of the sentence, or at the beginning of the paragraph--but in that
case using a \marginlabel as per the Companion

 
 Herbert
 
 -- 
 http://www.educat.hu-berlin.de/~voss/lyx/

-- 
Yves

Re: compile error

[Yves Bastide]

On Mon, Sep 03, 2001 at 03:44:48PM +0200, Edwin Leuven wrote:
 in today's cvs:
 
 main.o: In function 
 `__default_alloc_templatetrue,0::_S_chunk_alloc(unsigned int, int )': 
 /usr/include/g++-3/stl_alloc.h:467: undefined reference to 
 `GUIRunTime::initApplication(int, char **)'
 collect2: ld returned 1 exit status
a full rebuild (make distclean; ./autogen.sh; ./configure; ./make)
corrected it for me (may be too much)
 
 thanks, gr.ed.

-- 
Yves

Re: Bug list - Update No. 73251

[Yves Bastide]

On Mon, Sep 03, 2001 at 05:38:29PM +0200, Michael Schmitt wrote:
 On Mon, 3 Sep 2001, Yves Bastide wrote:
 
Is such fiddling appropriate, when all we have is a user bug ? :-)
A marginpar, like a footnote or an index entry, is meant to refer to the
preceding word.  No?
  
   no, as far as i know to the line of the \marginpar command.
   but it always works when it is near to the preceeding
   word, because there are no problems with hyphenation.
 
  You're right; still, I would put it either after the significant word, at
  the end of the sentence, or at the beginning of the paragraph--but in that
  case using a \marginlabel as per the Companion
 
 Just a few comments:
 
 The user may write legal LyX documents with margin pars that are not
 displayed correctly in the output. You argue that it is a user bug to use
 margin pars in certain contextes but I would like to point out that a
 user (like me) is not aware of making a fault at all.
 
 On other hand, there are probably more cases where a user can write LyX
 documents that do not make sense for Latex.
 
 I will remove the bug report from my list.

Sorry, I should have said a documentation bug.  \marginpar has even bigger
problems: it can only appear in normal text, it sometimes put the note on
the wrong side, it cannot appear at the start of the paragraph ...
That's why I think this particular bug is quite minor.

A possible patch would be:

--- src/insets/insetmarginal.C  2001/07/27 12:03:36 1.17
+++ src/insets/insetmarginal.C  2001/09/03 13:42:40
@@ -58,7 +58,7 @@ int InsetMarginal::latex(Buffer const * 
os  %\n\\marginpar{;
 
int const i = inset.latex(buf, os, fragile, fp);
-   os  %\n};
+   os  %\n}\n;
 
-   return i + 2;
+   return i + 3;
 }

... but I'm not sure at all that it is inocuitous.  Comments anyone?

 
 Michael
 
 
 -- 
 ==
 Michael Schmittphone: +49 451 500 3725
 Institute for Telematics   secretary: +49 451 500 3721
 Medical University of Luebeck  fax:   +49 451 500 3722
 Ratzeburger Allee 160  eMail: [EMAIL PROTECTED]
 D-23538 Luebeck, Germany   WWW:   http://www.itm.mu-luebeck.de
 ==

-- 
Yves

Re: reLyX bug

[Yves Bastide]

On Mon, Sep 03, 2001 at 07:17:38PM +0100, Jose Abilio Oliveira Matos wrote:
 
   Do you have any idea why Michael has problems with the reLyX path detection?

Hmm.  Michael, I don't understand this:
  Can't locate reLyXmain.pl in @INC (@INC contains:
  /home/schmitt/Programme/lyx-1.2.0cvs-sol/bin
  /opt/local/perl5.004/lib/5.00502/sun4-solaris
  /opt/local/perl5.004/lib/5.00502
  /opt/local/perl5.004/lib/site_perl/5.005/sun4-solaris
  /opt/local/perl5.004/lib/site_perl/5.005 .) at /opt/local/bin/reLyX line 72
   ^^

Would it be a remnant of an older installation?

Apart from that, I don't see where there may be a problem, with neither
version of perl...

   
   I really, really prefer python.
 
   And the code is so much readble...

But so much less fun... :-)
And you know that Amir's code is particularly readable

 
 -- 
 José

-- 
Yves

Re: reLyX bug

[Yves Bastide]

On Mon, Sep 03, 2001 at 10:45:16PM +0100, Jose Abilio Oliveira Matos wrote:
 

FOUND!

diff -u -p -r1.5 reLyX.in
--- lib/reLyX//reLyX.in 2001/08/31 07:54:05 1.5
+++ lib/reLyX//reLyX.in 2001/09/03 21:46:38
@@ -14,11 +14,13 @@ $^W = 1; # same as 'perl -w'
 use vars qw($lyxdir $lyxname);
 
 my (@maybe_dir);
-my $mainscript = reLyXmain.pl;
+my $mainscript;
 my $relyxdir;
 
 # Do this in a BEGIN block so it's done before the 'use lib' below
 BEGIN{
+# Variables may not be assigned before the BEGIN block
+$mainscript = reLyXmain.pl;
 # This points to LyX library dir, e.g. /usr/local/share/lyx
 $lyxdir = @LYX_DIR@;
 # This is just . if you compiled from the source directory


... and there was much rejoycing.


 I really, really prefer python.
   
 And the code is so much readble...
  
  But so much less fun... :-)
 
   Come on, that's not true. You can overload operators, use functional
 programming tools as I did in my last program. If that is not fun, used with
 classes I don't know what is. ;-)
 
   You can add a __cal__ method to a class making it a functor, and using it
 everywhere a function can be used. I don't even dream it how to do it in
 perl... ;-)

Oh, I'm not arguing against Python; whenever a friend try to convert me to
C#, I answer Python.  And I don't know either language yet ;-)

 
  And you know that Amir's code is particularly readable
 
   Why do you think that protesting I'm still hacking reLyX code? ;-)
   No only readable but also clean. Thanks, *Mr* Perl. ;-)

Yep.

   
  -- 
  Yves
 
 -- 
 José

-- 
Yves

Re: Bug list - Update No. 73251

[Yves Bastide]

On Mon, Sep 03, 2001 at 01:24:13PM +0200, Herbert Voss wrote:
> Michael Schmitt wrote:
> > 
> > On Mon, 3 Sep 2001, Herbert Voss wrote:
> > 
> > > this is your problem, not a latex one ...
> > > when you add your margin note _direct_ before the last word,
> > > than the parbox of the margin and the word are a unit(!) and
> > > hyphenation is not possible!
> > > a margin should always appear as a "word", means space before
> > > _and_ space behind, than all works well.
> > 
> > Aha! May I draw the conclusion that LyX should add a space before and
> > after each margin note automatically when exporting to LaTeX?
> 
> I was too quick with my answer. It may be a problem of hyphenation,
> because
>  
> \tolerance=200
> \setlength{\emergencystretch}{2em}
> 
> solve the problem ...
> 
> I'll have a closer look at it.

Is such fiddling appropriate, when all we have is a user bug ? :-)
A marginpar, like a footnote or an index entry, is meant to refer to the
preceding word.  No?

> 
> Herbert
> 
> 
> -- 
> http://www.educat.hu-berlin.de/~voss/lyx/

-- 
Yves

Re: Bug list - Update No. 73251

[Yves Bastide]

On Mon, Sep 03, 2001 at 02:38:00PM +0200, Herbert Voss wrote:
> Yves Bastide wrote:
> > 
> > Is such fiddling appropriate, when all we have is a user bug ? :-)
> > A marginpar, like a footnote or an index entry, is meant to refer to the
> > preceding word.  No?
> 
> no, as far as i know to the line of the \marginpar command.
> but it always works when it is near to the preceeding
> word, because there are no problems with hyphenation.

You're right; still, I would put it either after the significant word, at
the end of the sentence, or at the beginning of the paragraph--but in that
case using a \marginlabel as per the Companion

> 
> Herbert
> 
> -- 
> http://www.educat.hu-berlin.de/~voss/lyx/

-- 
Yves

Re: compile error

[Yves Bastide]

On Mon, Sep 03, 2001 at 03:44:48PM +0200, Edwin Leuven wrote:
> in today's cvs:
> 
> main.o: In function 
> `__default_alloc_template::_S_chunk_alloc(unsigned int, int &)': 
> /usr/include/g++-3/stl_alloc.h:467: undefined reference to 
> `GUIRunTime::initApplication(int, char **)'
> collect2: ld returned 1 exit status
a full rebuild (make distclean; ./autogen.sh; ./configure; ./make)
corrected it for me (may be too much)
> 
> thanks, gr.ed.

-- 
Yves

Re: Bug list - Update No. 73251

[Yves Bastide]

On Mon, Sep 03, 2001 at 05:38:29PM +0200, Michael Schmitt wrote:
> On Mon, 3 Sep 2001, Yves Bastide wrote:
> 
> > > > Is such fiddling appropriate, when all we have is a user bug ? :-)
> > > > A marginpar, like a footnote or an index entry, is meant to refer to the
> > > > preceding word.  No?
> > >
> > > no, as far as i know to the line of the \marginpar command.
> > > but it always works when it is near to the preceeding
> > > word, because there are no problems with hyphenation.
> >
> > You're right; still, I would put it either after the significant word, at
> > the end of the sentence, or at the beginning of the paragraph--but in that
> > case using a \marginlabel as per the Companion
> 
> Just a few comments:
> 
> The user may write legal LyX documents with margin pars that are not
> displayed correctly in the output. You argue that it is a user bug to use
> margin pars in certain contextes but I would like to point out that a
> user (like me) is not aware of making a fault at all.
> 
> On other hand, there are probably more cases where a user can write LyX
> documents that do not make sense for Latex.
> 
> I will remove the bug report from my list.

Sorry, I should have said a documentation bug.  \marginpar has even bigger
problems: it can only appear in normal text, it sometimes put the note on
the wrong side, it cannot appear at the start of the paragraph ...
That's why I think this particular bug is quite minor.

A possible patch would be:

--- src/insets/insetmarginal.C  2001/07/27 12:03:36 1.17
+++ src/insets/insetmarginal.C  2001/09/03 13:42:40
@@ -58,7 +58,7 @@ int InsetMarginal::latex(Buffer const * 
os << "%\n\\marginpar{";
 
int const i = inset.latex(buf, os, fragile, fp);
-   os << "%\n}";
+   os << "%\n}\n";
 
-   return i + 2;
+   return i + 3;
 }

... but I'm not sure at all that it is inocuitous.  Comments anyone?

> 
> Michael
> 
> 
> -- 
> ==
> Michael Schmittphone: +49 451 500 3725
> Institute for Telematics   secretary: +49 451 500 3721
> Medical University of Luebeck  fax:   +49 451 500 3722
> Ratzeburger Allee 160  eMail: [EMAIL PROTECTED]
> D-23538 Luebeck, Germany   WWW:   http://www.itm.mu-luebeck.de
> ==

-- 
Yves

Re: reLyX bug

[Yves Bastide]

On Mon, Sep 03, 2001 at 07:17:38PM +0100, Jose Abilio Oliveira Matos wrote:
> 
>   Do you have any idea why Michael has problems with the reLyX path detection?

Hmm.  Michael, I don't understand this:
> > Can't locate reLyXmain.pl in @INC (@INC contains:
> > /home/schmitt/Programme/lyx-1.2.0cvs-sol/bin
> > /opt/local/perl5.004/lib/5.00502/sun4-solaris
> > /opt/local/perl5.004/lib/5.00502
> > /opt/local/perl5.004/lib/site_perl/5.005/sun4-solaris
> > /opt/local/perl5.004/lib/site_perl/5.005 .) at /opt/local/bin/reLyX line 72
   ^^

Would it be a remnant of an older installation?

Apart from that, I don't see where there may be a problem, with neither
version of perl...

>   
>   I really, really prefer python.
> 
>   And the code is so much readble...

But so much less fun... :-)
And you know that Amir's code is particularly readable

> 
> -- 
> José

-- 
Yves

Re: reLyX bug

[Yves Bastide]

On Mon, Sep 03, 2001 at 10:45:16PM +0100, Jose Abilio Oliveira Matos wrote:
> 

FOUND!

diff -u -p -r1.5 reLyX.in
--- lib/reLyX//reLyX.in 2001/08/31 07:54:05 1.5
+++ lib/reLyX//reLyX.in 2001/09/03 21:46:38
@@ -14,11 +14,13 @@ $^W = 1; # same as 'perl -w'
 use vars qw($lyxdir $lyxname);
 
 my (@maybe_dir);
-my $mainscript = "reLyXmain.pl";
+my $mainscript;
 my $relyxdir;
 
 # Do this in a BEGIN block so it's done before the 'use lib' below
 BEGIN{
+# Variables may not be assigned before the BEGIN block
+$mainscript = "reLyXmain.pl";
 # This points to LyX library dir, e.g. /usr/local/share/lyx
 $lyxdir = "@LYX_DIR@";
 # This is just "." if you compiled from the source directory


... and there was much rejoycing.


> > >   I really, really prefer python.
> > > 
> > >   And the code is so much readble...
> > 
> > But so much less fun... :-)
> 
>   Come on, that's not true. You can overload operators, use functional
> programming tools as I did in my last program. If that is not fun, used with
> classes I don't know what is. ;-)
> 
>   You can add a __cal__ method to a class making it a functor, and using it
> everywhere a function can be used. I don't even dream it how to do it in
> perl... ;-)

Oh, I'm not arguing against Python; whenever a friend try to convert me to
C#, I answer Python.  And I don't know either language yet ;-)

> 
> > And you know that Amir's code is particularly readable
> 
>   Why do you think that protesting I'm still hacking reLyX code? ;-)
>   No only readable but also clean. Thanks, *Mr* Perl. ;-)

Yep.

>   
> > -- 
> > Yves
> 
> -- 
> José

-- 
Yves

Re: Bug list - Update No. 73251

[Yves Bastide]

On Fri, Aug 31, 2001 at 09:44:46PM +0100, John Levon wrote:
 On Fri, Aug 31, 2001 at 03:01:27PM +0200, Michael Schmitt wrote:
[snip]
  - Create a new document that contains the word Sophisticated 6 times. View the
dvi output (-last word is broken into two lines); add a margin note right in
front of the last word and view dvi output again (- the word is not broken any 
more but collides with the margin note); LyX or Latex bug???
 
 pass ...

I'd say Latex feature (a margin note should go after a word, not before)

[snip]
 
 john
 

-- 
Yves

Re: Bug list - Update No. 73251

[Yves Bastide]

On Fri, Aug 31, 2001 at 09:44:46PM +0100, John Levon wrote:
> On Fri, Aug 31, 2001 at 03:01:27PM +0200, Michael Schmitt wrote:
[snip]
> > - Create a new document that contains the word "Sophisticated" 6 times. View the
> >   dvi output (->last word is broken into two lines); add a margin note right in
> >   front of the last word and view dvi output again (-> the word is not broken any 
> >   more but collides with the margin note); LyX or Latex bug???
> 
> pass ...

I'd say Latex "feature" (a margin note should go after a word, not before)

[snip]
> 
> john
> 

-- 
Yves

Re: Free BSD fix to CVS

[Yves Bastide]

On Fri, Aug 31, 2001 at 12:32:48PM +0200, Lars Gullik Bjønnes wrote:
 R. Lahaye [EMAIL PROTECTED] writes:
 
 | Hi,
 | 
 | I'm running FreeBSD 4.3 (lattest official release) and there are problems
 | with the #include wchar lines in boost/boost/detail/limits.hpp.
 | All the wide character files are not available on a FreeBSD OS and may
 | not be included for quite some time. Therefore LyX needs to fix this for
 | a FreeBSD OS.
 
 are there wide string/char support in FreeBSD at all?
 
 I'll ask on the boost list if it is possible to check for the wide
 support there.

They do check (well, there's a BOOST_NO_INTRINSIC_WCHAR_T, for VC 6 at
least), but the #include cwchar is unconditionnal ...

[snip patch]
 
 close but remember that this needs to be done for every upgrade of
 the boost files.

Another approach (draft):

diff -u -p -r1.77 configure.in
--- configure.in2001/08/19 09:33:45 1.77
+++ configure.in2001/08/31 10:43:29
@@ -82,6 +82,10 @@ LYX_CXX_EXPLICIT
 LYX_CXX_STL_STRING
 LYX_CXX_GOOD_STD_STRING
 LYX_CXX_CHEADERS
+AC_CHECK_HEADER(cwchar,
+  [],
+  [ LYX_ADD_INC_DIR(lyx_cppflags,\$(top_srcdir)/src/cheaders/wchar) ]
+)
 LYX_CXX_GLOBAL_CSTD
 LYX_STD_COUNT
 dnl we disable rtti for now


And:
$ cat src/cheaders/wchar/cwchar
// -*- c++ -*-
// Empty cwchar for systems which don't have it
// (e.g., FreeBSD 4.3)
// We don't even pretend it to be real (no WCHAR_MIN, etc.)

  
 | Regards,
 | Rob.
 | 
 
 -- 
   Lgb

-- 
Yves

Re: reLyX bug

[Yves Bastide]

On Fri, Aug 31, 2001 at 11:30:32AM +0100, Jose Abilio Oliveira Matos wrote:
[snip]
  
  Yeah, that's OK too.
 
   Actually I have choosen your alternative, I really dislike the ()-, grrr...
 (sorry Yves, nothing personal, on the other hand since today is friday it
 is after all).

Ok.  Wait till I send you a list of DR.  (Hint: the first one would be a
bug I asked Amir to introduce, all those years back)

[snip]

-- 
Yves

Re: Free BSD fix to CVS

[Yves Bastide]

On Fri, Aug 31, 2001 at 12:32:48PM +0200, Lars Gullik Bjønnes wrote:
> "R. Lahaye" <[EMAIL PROTECTED]> writes:
> 
> | Hi,
> | 
> | I'm running FreeBSD 4.3 (lattest official release) and there are problems
> | with the "#include " lines in boost/boost/detail/limits.hpp.
> | All the wide character files are not available on a FreeBSD OS and may
> | not be included for quite some time. Therefore LyX needs to fix this for
> | a FreeBSD OS.
> 
> are there wide string/char support in FreeBSD at all?
> 
> I'll ask on the boost list if it is possible to check for the wide
> support there.

They do check (well, there's a BOOST_NO_INTRINSIC_WCHAR_T, for VC 6 at
least), but the #include  is unconditionnal ...

[snip patch]
> 
> close but remember that this needs to be done for every upgrade of
> the boost files.

Another approach (draft):

diff -u -p -r1.77 configure.in
--- configure.in2001/08/19 09:33:45 1.77
+++ configure.in2001/08/31 10:43:29
@@ -82,6 +82,10 @@ LYX_CXX_EXPLICIT
 LYX_CXX_STL_STRING
 LYX_CXX_GOOD_STD_STRING
 LYX_CXX_CHEADERS
+AC_CHECK_HEADER(cwchar,
+  [],
+  [ LYX_ADD_INC_DIR(lyx_cppflags,\$(top_srcdir)/src/cheaders/wchar) ]
+)
 LYX_CXX_GLOBAL_CSTD
 LYX_STD_COUNT
 dnl we disable rtti for now


And:
$ cat src/cheaders/wchar/cwchar
// -*- c++ -*-
// Empty cwchar for systems which don't have it
// (e.g., FreeBSD 4.3)
// We don't even pretend it to be real (no WCHAR_MIN, etc.)

>  
> | Regards,
> | Rob.
> | 
> 
> -- 
>   Lgb

-- 
Yves

Re: reLyX bug

[Yves Bastide]

On Fri, Aug 31, 2001 at 11:30:32AM +0100, Jose Abilio Oliveira Matos wrote:
[snip]
> > 
> > Yeah, that's OK too.
> 
>   Actually I have choosen your alternative, I really dislike the ()->, grrr...
> (sorry Yves, nothing personal, on the other hand since today is friday it
> is after all).

Ok.  Wait till I send you a list of DR.  (Hint: the first one would be a
bug I asked Amir to introduce, all those years back)

[snip]

-- 
Yves

Re: reLyX bug

[Yves Bastide]

On Wed, Aug 29, 2001 at 06:42:11PM +0100, Jose Abilio Oliveira Matos wrote:
[snip]
 
  305  if( $Latex_Preamble =~ /\\geometry\{(.*)\}/) {
  306  my $geom_options = $1;
  307  my $op;
  308  foreach $op (keys %Geometry_Options) {
  309  $geom_options =~ s/$op//  do {
  310  $LyX_Preamble .= $Geometry_Options{$op}();

for Perl  5.6, you need
$LyX_Preamble .= $Geometry_Options{$op}-();
(should I send a patch for this one-liner?)

  311  print Geometry option $op\n if $debug_on;
  312  }
  313  }
 ...
 
[snip]
 
 -- 
 José

-- 
Yves

Re: reLyX bug

[Yves Bastide]

On Thu, Aug 30, 2001 at 12:07:39PM +0100, Jose Abilio Oliveira Matos wrote:
[snip]
 
   Unless you have other features/bug fixes it easier to add it my self than
 to have all the trouble with patching and unpatching. ;-)

:-)

If you ask so:

- reLyXmain.pl: 97  \\documentclass, not \documentclass

- many regexes: you could liberally add \s* ... For instance to recognize
  \geometry {
a4paper,
verbose,
tmargin = 3 cm
  }
  But this should certainly be done as a pre-processing somewhere

 
311  print Geometry option $op\n if $debug_on;
312  }
313  }
   ...
 
   Thanks. :-)

My pleasure!

   
  -- 
  Yves
 
 -- 
 José

-- 
Yves

Re: reLyX bug

[Yves Bastide]

On Wed, Aug 29, 2001 at 06:42:11PM +0100, Jose Abilio Oliveira Matos wrote:
[snip]
> 
>  305  if( $Latex_Preamble =~ /\\geometry\{(.*)\}/) {
>  306  my $geom_options = $1;
>  307  my $op;
>  308  foreach $op (keys %Geometry_Options) {
>  309  $geom_options =~ s/$op// && do {
>  310  $LyX_Preamble .= $Geometry_Options{$op}();

for Perl < 5.6, you need
$LyX_Preamble .= $Geometry_Options{$op}->();
(should I send a patch for this one-liner?)

>  311  print "Geometry option $op\n" if $debug_on;
>  312  }
>  313  }
> ...
> 
[snip]
> 
> -- 
> José

-- 
Yves

Re: reLyX bug

[Yves Bastide]

On Thu, Aug 30, 2001 at 12:07:39PM +0100, Jose Abilio Oliveira Matos wrote:
[snip]
> 
>   Unless you have other features/bug fixes it easier to add it my self than
> to have all the trouble with patching and unpatching. ;-)

:-)

If you ask so:

- reLyXmain.pl: 97  \\documentclass, not \documentclass

- many regexes: you could liberally add \s* ... For instance to recognize
  \geometry {
a4paper,
verbose,
tmargin = 3 cm
  }
  But this should certainly be done as a pre-processing somewhere

> 
> > >  311  print "Geometry option $op\n" if $debug_on;
> > >  312  }
> > >  313  }
> > > ...
> 
>   Thanks. :-)

My pleasure!

>   
> > -- 
> > Yves
> 
> -- 
> José

-- 
Yves

Small bug in src/mathed/math_parser.C

[Yves Bastide]

Hmm, I am alone in seeing this problem? :-)

Index: src/mathed/math_parser.C
===
RCS file: /cvs/lyx/lyx-devel/src/mathed/math_parser.C,v
retrieving revision 1.125
diff -u -p -r1.125 math_parser.C
--- src/mathed/math_parser.C2001/08/29 16:23:54 1.125
+++ src/mathed/math_parser.C2001/08/29 20:09:16
@@ -393,7 +393,7 @@ void Parser::tokenize(string const  buf
init_done = true;
}
 
-   istringstream is(buffer, ios::in | ios::binary);
+   istringstream is(buffer.c_str(), ios::in | ios::binary);
 
char c;
while (is.get(c)) {


Regards,

-- 
Yves

Re: Small bug in src/mathed/math_parser.C

[Yves Bastide]

On Wed, Aug 29, 2001 at 10:19:09PM +0200, Lars Gullik Bjønnes wrote:
 [EMAIL PROTECTED] (Yves Bastide) writes:
 
 | Hmm, I am alone in seeing this problem? :-)
 | 
 | Index: src/mathed/math_parser.C
 | ===
 | RCS file: /cvs/lyx/lyx-devel/src/mathed/math_parser.C,v
 | retrieving revision 1.125
 | diff -u -p -r1.125 math_parser.C
 | --- src/mathed/math_parser.C2001/08/29 16:23:54 1.125
 | +++ src/mathed/math_parser.C2001/08/29 20:09:16
 | @@ -393,7 +393,7 @@ void Parser::tokenize(string const  buf
 | init_done = true;
 | }
 |  
 | -   istringstream is(buffer, ios::in | ios::binary);
 | +   istringstream is(buffer.c_str(), ios::in | ios::binary);
 
 Why do you need this? it should not be needed.
 
 let me guess... lyxstring ... and systems sstream (and system really
 has a std::string that is usable as well.)

Yes... silly grin

Solution: don't use lyxstring unless really necessary...

Thanks,

 
 -- 
   Lgb

-- 
Yves

Small bug in src/mathed/math_parser.C

[Yves Bastide]

Hmm, I am alone in seeing this problem? :-)

Index: src/mathed/math_parser.C
===
RCS file: /cvs/lyx/lyx-devel/src/mathed/math_parser.C,v
retrieving revision 1.125
diff -u -p -r1.125 math_parser.C
--- src/mathed/math_parser.C2001/08/29 16:23:54 1.125
+++ src/mathed/math_parser.C2001/08/29 20:09:16
@@ -393,7 +393,7 @@ void Parser::tokenize(string const & buf
init_done = true;
}
 
-   istringstream is(buffer, ios::in | ios::binary);
+   istringstream is(buffer.c_str(), ios::in | ios::binary);
 
char c;
while (is.get(c)) {


Regards,

-- 
Yves

Re: Small bug in src/mathed/math_parser.C

[Yves Bastide]

On Wed, Aug 29, 2001 at 10:19:09PM +0200, Lars Gullik Bjønnes wrote:
> [EMAIL PROTECTED] (Yves Bastide) writes:
> 
> | Hmm, I am alone in seeing this problem? :-)
> | 
> | Index: src/mathed/math_parser.C
> | ===
> | RCS file: /cvs/lyx/lyx-devel/src/mathed/math_parser.C,v
> | retrieving revision 1.125
> | diff -u -p -r1.125 math_parser.C
> | --- src/mathed/math_parser.C2001/08/29 16:23:54 1.125
> | +++ src/mathed/math_parser.C2001/08/29 20:09:16
> | @@ -393,7 +393,7 @@ void Parser::tokenize(string const & buf
> | init_done = true;
> | }
> |  
> | -   istringstream is(buffer, ios::in | ios::binary);
> | +   istringstream is(buffer.c_str(), ios::in | ios::binary);
> 
> Why do you need this? it should not be needed.
> 
> let me guess... lyxstring ... and systems sstream (and system really
> has a std::string that is usable as well.)

Yes... 

Solution: don't use lyxstring unless really necessary...

Thanks,

> 
> -- 
>   Lgb

-- 
Yves

Re: isBuilt isBroken (C++ question)

[Yves Bastide]

On Mon, Aug 27, 2001 at 08:21:50AM +0200, Andre Poenitz wrote:
   60 template class Base
   61 void ControlDialogBase::show()
   62 {
   63 if (isBufferDependent()  !lv_.view()-available())
   64 return;
   65
   66 setParams();
   67
   68 static bool isBuilt = false;
   69 if (!isBuilt) {
   70 isBuilt = true;
   71 view().build();
   72 }
  
  
  unfortunately, the static seems to be sharing itself with all templatised
  objects. How can we get the expected per-dialog isBuilt() functionality ?
 
 That observation does not fit too well into my understanding of how C++
 works, but I don't have the standard around for proper investigation.
 
 I'd say every instance of the function should have its own static. How else
 could it work when the type of 'isBuilt' depents on the template parameter?

It works the right way (G++ 3.0).  isBuilt is not per-dialog, but per
dialog class.

 
 Andre'
 
 -- 
 André Pönitz . [EMAIL PROTECTED]

-- 
Yves

Re: isBuilt isBroken (C++ question)

[Yves Bastide]

On Mon, Aug 27, 2001 at 08:21:50AM +0200, Andre Poenitz wrote:
> >  60 template 
> >  61 void ControlDialog::show()
> >  62 {
> >  63 if (isBufferDependent() && !lv_.view()->available())
> >  64 return;
> >  65
> >  66 setParams();
> >  67
> >  68 static bool isBuilt = false;
> >  69 if (!isBuilt) {
> >  70 isBuilt = true;
> >  71 view().build();
> >  72 }
> > 
> > 
> > unfortunately, the static seems to be sharing itself with all templatised
> > objects. How can we get the expected per-dialog isBuilt() functionality ?
> 
> That observation does not fit too well into my understanding of how C++
> works, but I don't have the standard around for proper investigation.
> 
> I'd say every instance of the function should have its own static. How else
> could it work when the type of 'isBuilt' depents on the template parameter?

It works the right way (G++ 3.0).  isBuilt is not per-dialog, but per
dialog class.

> 
> Andre'
> 
> -- 
> André Pönitz . [EMAIL PROTECTED]

-- 
Yves

Re: isBuilt isBroken (C++ question)

[Yves Bastide]

On Sat, Aug 25, 2001 at 09:56:49PM +0100, John Levon wrote:
 
 Angus recently added isBuilt() in controllers/ to make sure that
 the dialog is built before changing its readonly stuff.
 
  60 template class Base
  61 void ControlDialogBase::show()
  62 {
  63 if (isBufferDependent()  !lv_.view()-available())
  64 return;
  65
  66 setParams();
  67
  68 static bool isBuilt = false;
  69 if (!isBuilt) {
  70 isBuilt = true;
  71 view().build();
  72 }
 
 
 unfortunately, the static seems to be sharing itself with all templatised
 objects. How can we get the expected per-dialog isBuilt() functionality ?

Your void ControlDialogBase::show() is common to all objects of type
Base.  Why don't you just use a data member?  Rough draft:
template class Base
class ControlDialog {
...
private:
...
class State {
public:
bool isBuilt;
State() : isBuilt(false) {}
};
State state_;
};

template class Base
void ControlDialogBase::show()
{
...
if (!state_.isBuilt) {
state_.isBuilt = true;
...
} 
...
}

 
 thanks
 john
 
 -- 
 That's just kitten-eating wrong.
   - Richard Henderson

-- 
Yves

Re: isBuilt isBroken (C++ question)

[Yves Bastide]

On Sat, Aug 25, 2001 at 09:56:49PM +0100, John Levon wrote:
> 
> Angus recently added isBuilt() in controllers/ to make sure that
> the dialog is built before changing its readonly stuff.
> 
>  60 template 
>  61 void ControlDialog::show()
>  62 {
>  63 if (isBufferDependent() && !lv_.view()->available())
>  64 return;
>  65
>  66 setParams();
>  67
>  68 static bool isBuilt = false;
>  69 if (!isBuilt) {
>  70 isBuilt = true;
>  71 view().build();
>  72 }
> 
> 
> unfortunately, the static seems to be sharing itself with all templatised
> objects. How can we get the expected per-dialog isBuilt() functionality ?

Your void ControlDialog::show() is common to all objects of type
"Base".  Why don't you just use a data member?  Rough draft:
template 
class ControlDialog {
...
private:
...
class State {
public:
bool isBuilt;
State() : isBuilt(false) {}
};
State state_;
};

template 
void ControlDialog::show()
{
...
if (!state_.isBuilt) {
state_.isBuilt = true;
...
} 
...
}

> 
> thanks
> john
> 
> -- 
> "That's just kitten-eating wrong."
>   - Richard Henderson

-- 
Yves

Re: RPM files

[Yves Bastide]

On Fri, Aug 17, 2001 at 09:30:24AM +0200, Juergen Vigna wrote:
 
 On 16-Aug-2001 Zvezdan Petkovic wrote:
 
  That way my rpm shell script is executed when I type rpm ...
  It adds my rpmrc file, and it adds my macros file. Hence the topdir and
  tmppath get changed to my directories and I can build as a regular user.
 
 I did this but then the files in the rpm-package have my user-id and group-id
 instead of root:root (or whatever it should have) and then on installing 
 on systems where I don't have such a user I get warnings about user non
 existing substituting with root and I don't like that warnings. What I do
 is test-build as user (for the same resons as you) but then build the final
 as root.

Debian has a fakeroot command: basically a library LD_PRELOADed to
return uid=0.  I expect either it exists also on rpm systems or you can get
it somewhere

 
  Jürgen
 
 --
 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
 Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
 Italienallee 13/N   Tel/Fax: +39-0471-450260 / +39-0471-450253
 I-39100 Bozen   Web: http://www.sad.it/~jug
 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
 
 Someone is unenthusiastic about your work.

-- 
Yves

Re: RPM files

[Yves Bastide]

On Fri, Aug 17, 2001 at 09:30:24AM +0200, Juergen Vigna wrote:
> 
> On 16-Aug-2001 Zvezdan Petkovic wrote:
> 
> > That way my rpm shell script is executed when I type rpm ...
> > It adds my rpmrc file, and it adds my macros file. Hence the topdir and
> > tmppath get changed to my directories and I can build as a regular user.
> 
> I did this but then the files in the rpm-package have my user-id and group-id
> instead of root:root (or whatever it should have) and then on installing 
> on systems where I don't have such a user I get warnings about user non
> existing substituting with root and I don't like that warnings. What I do
> is test-build as user (for the same resons as you) but then build the final
> as root.

Debian has a fakeroot command: basically a library LD_PRELOADed to
return uid=0.  I expect either it exists also on rpm systems or you can get
it somewhere

> 
>  Jürgen
> 
> --
> -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
> Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
> Italienallee 13/N   Tel/Fax: +39-0471-450260 / +39-0471-450253
> I-39100 Bozen   Web: http://www.sad.it/~jug
> -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
> 
> Someone is unenthusiastic about your work.

-- 
Yves

Re: RPM files

[Yves Bastide]

On Thu, Aug 16, 2001 at 08:41:23PM +0200, Ronny Buchmann wrote:
 * Zvezdan Petkovic [EMAIL PROTECTED] [2001-08-16 19:59] wrote:
  On Thu, Aug 16, 2001 at 07:33:55PM +0200, Ronny Buchmann wrote:
   the point is, that its not clear, which macros are supported in which
   rpm version so maybe zvezdan's rpms dont compile on (older) suse imo
   the spec files should be compatible with at least the last 6. versions
   from suse and redhat if one has a testsystem with say suse 6.4 (redhat
   has already rpm-4 in its updates for 6.2) i could make a test
   spec-file to see what macros are working

   -- 
   ronny
  
  That's why I said on that web page:
  
  Hence, it should be usable on any RPM based Linux distribution (at
  least those with rpm-4.x).
  
  As a sysadmin I regularly apply all Red Hat updates -- hence my 6.2
  systems run rpm-4.x. I'm sorry I couldn't test it with the older version
  of rpm. 
 suse (and possibly others) uses still rpm-3.x
 outside the US there seem to be much more distris in wide use
  

Mandrake 8 uses rpm 4.  Just installed Zvezdan's package, it seems alright

 
 -- 
 ronny

-- 
Yves, happy Debian user otherwise

Re: RPM files

[Yves Bastide]

On Thu, Aug 16, 2001 at 08:41:23PM +0200, Ronny Buchmann wrote:
> * Zvezdan Petkovic <[EMAIL PROTECTED]> [2001-08-16 19:59] wrote:
> > On Thu, Aug 16, 2001 at 07:33:55PM +0200, Ronny Buchmann wrote:
> > > the point is, that its not clear, which macros are supported in which
> > > rpm version so maybe zvezdan's rpms dont compile on (older) suse imo
> > > the spec files should be compatible with at least the last 6. versions
> > > from suse and redhat if one has a testsystem with say suse 6.4 (redhat
> > > has already rpm-4 in its updates for 6.2) i could make a test
> > > spec-file to see what macros are working
> > >  
> > > -- 
> > > ronny
> > 
> > That's why I said on that web page:
> > 
> > "Hence, it should be usable on any RPM based Linux distribution (at
> > least those with rpm-4.x)."
> > 
> > As a sysadmin I regularly apply all Red Hat updates -- hence my 6.2
> > systems run rpm-4.x. I'm sorry I couldn't test it with the older version
> > of rpm. 
> suse (and possibly others) uses still rpm-3.x
> outside the US there seem to be much more distris in wide use
>  

Mandrake 8 uses rpm 4.  Just installed Zvezdan's package, it seems alright

> 
> -- 
> ronny

-- 
Yves, happy Debian user otherwise

Quotes, once more

[Yves Bastide]

Promise, this is my last patch about quotes (:

This one displays ' as ´ if an appropriate encoding is used, and french
guillemets are also displayed in 8859-9 (some encodings dont't support
both quotes, but they are not yet handled separatly by LyX)

-- 
Yves


Index: src/insets/ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/src/insets/ChangeLog,v
retrieving revision 1.154
diff -u -p -r1.154 ChangeLog
--- src/insets/ChangeLog2001/07/25 22:05:53 1.154
+++ src/insets/ChangeLog2001/07/27 07:43:01
@@ -1,3 +1,8 @@
+2001-07-26  Yves Bastide  [EMAIL PROTECTED]
+
+   * insetquotes.C (dispString): display the right ISO8859-{1,9,15}
+   quotes
+
 2001-07-26  Lars Gullik Bjønnes  [EMAIL PROTECTED]
 
* insetminipage.C (read): handle missing parameters more gracefully
Index: src/insets/insetquotes.C
===
RCS file: /cvs/lyx/lyx-devel/src/insets/insetquotes.C,v
retrieving revision 1.53
diff -u -p -r1.53 insetquotes.C
--- src/insets/insetquotes.C2001/07/23 10:04:17 1.53
+++ src/insets/insetquotes.C2001/07/27 07:43:01
@@ -153,11 +153,17 @@ string const InsetQuotes::dispString(Lan
disp += disp;
 
if (lyxrc.font_norm_type == LyXRC::ISO_8859_1
-   || lyxrc.font_norm_type == LyXRC::ISO_8859_15)
-   if (disp == )
+   || lyxrc.font_norm_type == LyXRC::ISO_8859_9
+   || lyxrc.font_norm_type == LyXRC::ISO_8859_15) {
+   if (disp == ')
+   disp = ´;
+   else if (disp == '')
+   disp = ´´;
+   else if (disp == )
disp = '«';
else if (disp == )
disp = '»';
+   }
 
// in french, spaces are added inside double quotes
if (times_ == DoubleQ  prefixIs(loclang-code(), fr)) {

Quotes, once more

[Yves Bastide]

Promise, this is my last patch about quotes (:

This one displays ' as ´ if an appropriate encoding is used, and french
guillemets are also displayed in 8859-9 (some encodings dont't support
both quotes, but they are not yet handled separatly by LyX)

-- 
Yves


Index: src/insets/ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/src/insets/ChangeLog,v
retrieving revision 1.154
diff -u -p -r1.154 ChangeLog
--- src/insets/ChangeLog2001/07/25 22:05:53 1.154
+++ src/insets/ChangeLog2001/07/27 07:43:01
@@ -1,3 +1,8 @@
+2001-07-26  Yves Bastide  <[EMAIL PROTECTED]>
+
+   * insetquotes.C (dispString): display the right ISO8859-{1,9,15}
+   quotes
+
 2001-07-26  Lars Gullik Bjønnes  <[EMAIL PROTECTED]>
 
* insetminipage.C (read): handle missing parameters more gracefully
Index: src/insets/insetquotes.C
===
RCS file: /cvs/lyx/lyx-devel/src/insets/insetquotes.C,v
retrieving revision 1.53
diff -u -p -r1.53 insetquotes.C
--- src/insets/insetquotes.C2001/07/23 10:04:17 1.53
+++ src/insets/insetquotes.C2001/07/27 07:43:01
@@ -153,11 +153,17 @@ string const InsetQuotes::dispString(Lan
disp += disp;
 
if (lyxrc.font_norm_type == LyXRC::ISO_8859_1
-   || lyxrc.font_norm_type == LyXRC::ISO_8859_15)
-   if (disp == "<<")
+   || lyxrc.font_norm_type == LyXRC::ISO_8859_9
+   || lyxrc.font_norm_type == LyXRC::ISO_8859_15) {
+   if (disp == "'")
+   disp = "´";
+   else if (disp == "''")
+   disp = "´´";
+   else if (disp == "<<")
disp = '«';
else if (disp == ">>")
disp = '»';
+   }
 
// in french, spaces are added inside double quotes
if (times_ == DoubleQ && prefixIs(loclang->code(), "fr")) {

Re: Patch LyX 1.1.6fix3: use frenchb guillemets

[Yves Bastide]

On Mon, Jul 23, 2001 at 12:14:14PM +0200, Jean-Marc Lasgouttes wrote:
  Yves == Yves Bastide [EMAIL PROTECTED] writes:
 
 Yves There were two problems: when using a language other than french
 Yves or frenchb, no french quotes were inserted. And {} was missing
 Yves after \fg, eating a possible linebreak. The following patch
 Yves cures both of them.
 
 I have applied you patch (stupid oversight indeed), except that I
 removed the space after \fg{}, which seems to defeat the whole thing.
 Or maybe I do not understand what you mean.
The extra space should be harmless; the problem was in (C notation) \\fg\n
 
 Yves Note that there is still one problem with frenchb: the output of
 Yves \of and \fg depends on the language in use when they are
 Yves invoked, not on the global language; 
 
 I fixed this problem in the display part, but not on the latex part,
 unfortunately: in the latex() method, the current font (hence the
 current language) are not known. I really do not know what I can do to
 fix this :(
I think the best fix would be to document this somewhere.  And perhaps not
until someone notices it (:

 
 JMarc

-- 
Yves

Re: Patch LyX 1.1.6fix3: use frenchb guillemets

[Yves Bastide]

On Mon, Jul 23, 2001 at 12:14:14PM +0200, Jean-Marc Lasgouttes wrote:
> >>>>> "Yves" == Yves Bastide <[EMAIL PROTECTED]> writes:
> 
> Yves> There were two problems: when using a language other than french
> Yves> or frenchb, no french quotes were inserted. And {} was missing
> Yves> after \fg, eating a possible linebreak. The following patch
> Yves> cures both of them.
> 
> I have applied you patch (stupid oversight indeed), except that I
> removed the space after \fg{}, which seems to defeat the whole thing.
> Or maybe I do not understand what you mean.
The extra space should be harmless; the problem was in (C notation) \\fg\n
> 
> Yves> Note that there is still one problem with frenchb: the output of
> Yves> \of and \fg depends on the language in use when they are
> Yves> invoked, not on the global language; 
> 
> I fixed this problem in the display part, but not on the latex part,
> unfortunately: in the latex() method, the current font (hence the
> current language) are not known. I really do not know what I can do to
> fix this :(
I think the best fix would be to document this somewhere.  And perhaps not
until someone notices it (:

> 
> JMarc

-- 
Yves

Re: Patch LyX 1.1.6fix3: use frenchb guillemets

[Yves Bastide]

On Fri, Jul 20, 2001 at 03:58:39PM +0200, Jean-Marc Lasgouttes wrote:
  Yves == Yves Bastide [EMAIL PROTECTED] writes:
 
 Yves Hi, Here's a proposed patch to use frenchb's guillemets \og and
 Yves \fg (which have proper spacing) when using frenchb. The current
 Yves code does it only when fontenc != T1 -- not frequent among
 Yves French writers (:
 
 Yves (This patch is for 1.1.6; I can prepare another for -devel if
 Yves accepted.)
 
 Yves, could you checkwhat I did for 1.2.0? If it works well, I may
 adapt it to 1.1.6 too.

There were two problems: when using a language other than french or
frenchb, no french quotes were inserted.  And {} was missing after \fg,
eating a possible linebreak.  The following patch cures both of them.

Note that there is still one problem with frenchb: the output of \of and
\fg depends on the language in use when they are invoked, not on the global
language; i.e.
« a » « a » « a »
  ^ Layout/Characters/Language American
is output as « a » ``a''  « a »
-- with the wrong quotes and one extra space.  I don't know if
InsetQuotes::latex needs more tinkering around this feature, though...

 
 JMarc

-- 
Yves


Index: src/insets/ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/src/insets/ChangeLog,v
retrieving revision 1.142
diff -u -p -r1.142 ChangeLog
--- src/insets/ChangeLog2001/07/20 16:29:54 1.142
+++ src/insets/ChangeLog2001/07/20 23:05:53
@@ -1,3 +1,8 @@
+2001-07-21  Yves Bastide  [EMAIL PROTECTED]
+
+   * insetquotes.C (latex): fix the handling of french double quotes
+   when not using the french pachage.
+
 2001-07-20  Jean-Marc Lasgouttes  [EMAIL PROTECTED]
 
* insetindex.h: shut off warning
Index: src/insets/insetquotes.C
===
RCS file: /cvs/lyx/lyx-devel/src/insets/insetquotes.C,v
retrieving revision 1.51
diff -u -p -r1.51 insetquotes.C
--- src/insets/insetquotes.C2001/07/20 09:38:18 1.51
+++ src/insets/insetquotes.C2001/07/20 23:05:53
@@ -253,18 +253,18 @@ int InsetQuotes::latex(Buffer const * bu
int quoteind = quote_index[side_][language_];
string qstr;

-   if (language_ == FrenchQ  times_ == DoubleQ) {
-   if (doclang == frenchb) {
-   if (side_ == LeftQ) 
-   qstr = \\og ; //the spaces are important here
-   else 
-   qstr =  \\fg ; //and here
-   } else if (doclang == french) {
-   if (side_ == LeftQ) 
-   qstr =  ; //the spaces are important here
-   else 
-   qstr =  ; //and here
-   }   
+   if (language_ == FrenchQ  times_ == DoubleQ
+doclang == frenchb) {
+   if (side_ == LeftQ) 
+   qstr = \\og ; //the spaces are important here
+   else 
+   qstr =  \\fg{} ; //and here
+   } else if (language_ == FrenchQ  times_ == DoubleQ
+   doclang == french) {
+   if (side_ == LeftQ) 
+   qstr =  ; //the spaces are important here
+   else 
+   qstr =  ; //and here
} else if (lyxrc.fontenc == T1) {
qstr = latex_quote_t1[times_][quoteind];
 #ifdef DO_USE_DEFAULT_LANGUAGE

Re: Patch LyX 1.1.6fix3: use frenchb guillemets

[Yves Bastide]

On Fri, Jul 20, 2001 at 03:58:39PM +0200, Jean-Marc Lasgouttes wrote:
> >>>>> "Yves" == Yves Bastide <[EMAIL PROTECTED]> writes:
> 
> Yves> Hi, Here's a proposed patch to use frenchb's guillemets \og and
> Yves> \fg (which have proper spacing) when using frenchb. The current
> Yves> code does it only when fontenc != T1 -- not frequent among
> Yves> French writers (:
> 
> Yves> (This patch is for 1.1.6; I can prepare another for -devel if
> Yves> accepted.)
> 
> Yves, could you checkwhat I did for 1.2.0? If it works well, I may
> adapt it to 1.1.6 too.

There were two problems: when using a language other than french or
frenchb, no french quotes were inserted.  And {} was missing after \fg,
eating a possible linebreak.  The following patch cures both of them.

Note that there is still one problem with frenchb: the output of \of and
\fg depends on the language in use when they are invoked, not on the global
language; i.e.
« a » « a » « a »
  ^ Layout/Characters/Language American
is output as « a » ``a''  « a »
-- with the wrong quotes and one extra space.  I don't know if
InsetQuotes::latex needs more tinkering around this feature, though...

> 
> JMarc

-- 
Yves


Index: src/insets/ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/src/insets/ChangeLog,v
retrieving revision 1.142
diff -u -p -r1.142 ChangeLog
--- src/insets/ChangeLog2001/07/20 16:29:54 1.142
+++ src/insets/ChangeLog2001/07/20 23:05:53
@@ -1,3 +1,8 @@
+2001-07-21  Yves Bastide  <[EMAIL PROTECTED]>
+
+   * insetquotes.C (latex): fix the handling of french double quotes
+   when not using the french pachage.
+
 2001-07-20  Jean-Marc Lasgouttes  <[EMAIL PROTECTED]>
 
* insetindex.h: shut off warning
Index: src/insets/insetquotes.C
===
RCS file: /cvs/lyx/lyx-devel/src/insets/insetquotes.C,v
retrieving revision 1.51
diff -u -p -r1.51 insetquotes.C
--- src/insets/insetquotes.C2001/07/20 09:38:18 1.51
+++ src/insets/insetquotes.C2001/07/20 23:05:53
@@ -253,18 +253,18 @@ int InsetQuotes::latex(Buffer const * bu
int quoteind = quote_index[side_][language_];
string qstr;

-   if (language_ == FrenchQ && times_ == DoubleQ) {
-   if (doclang == "frenchb") {
-   if (side_ == LeftQ) 
-   qstr = "\\og "; //the spaces are important here
-   else 
-   qstr = " \\fg "; //and here
-   } else if (doclang == "french") {
-   if (side_ == LeftQ) 
-   qstr = "<< "; //the spaces are important here
-   else 
-   qstr = " >>"; //and here
-   }   
+   if (language_ == FrenchQ && times_ == DoubleQ
+   && doclang == "frenchb") {
+   if (side_ == LeftQ) 
+   qstr = "\\og "; //the spaces are important here
+   else 
+   qstr = " \\fg{} "; //and here
+   } else if (language_ == FrenchQ && times_ == DoubleQ
+  && doclang == "french") {
+   if (side_ == LeftQ) 
+   qstr = "<< "; //the spaces are important here
+   else 
+   qstr = " >>"; //and here
} else if (lyxrc.fontenc == "T1") {
qstr = latex_quote_t1[times_][quoteind];
 #ifdef DO_USE_DEFAULT_LANGUAGE

Re: math font changes while moving

[Yves Bastide]

On Fri, Jul 13, 2001 at 03:57:36PM +0200, Andre Poenitz wrote:
[snip]
 How would we export that? \mbox{contents}?
[snip]

Perhaps another item for the bottom of your todo list: use AMS's \text
instead of \mbox.  It supports accented characters, among others...
(selected via validate()?)

 
 Andre'
 
 
 -- 
 André Pönitz . [EMAIL PROTECTED]

-- 
Yves

Latin9

[Yves Bastide]

Hi,

this small patch adds a bit to the Latin9 support in LyX: with it, french
guillemets are displayed if the screen font is 8859-15.

It might also be worth adding with iso10646-1 ?..

Thanks,

-- 
Yves


Index: src/ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/src/ChangeLog,v
retrieving revision 1.230
diff -u -p -r1.230 ChangeLog
--- src/ChangeLog   2001/07/13 14:03:41 1.230
+++ src/ChangeLog   2001/07/13 17:13:13
@@ -1,3 +1,9 @@
+2001-07-13  Yves Bastide  [EMAIL PROTECTED]
+
+   * lyxrc.C (set_font_norm_type): recognise ISO_8859_15.
+
+   * lyxrc.h: added ISO_8859_15 to enum FontEncoding.
+
 2001-07-13  Angus Leeming  [EMAIL PROTECTED]
 
Consistent use of Lsstream.h:
Index: src/lyxrc.C
===
RCS file: /cvs/lyx/lyx-devel/src/lyxrc.C,v
retrieving revision 1.88
diff -u -p -r1.88 lyxrc.C
--- src/lyxrc.C 2001/06/29 11:54:38 1.88
+++ src/lyxrc.C 2001/07/13 17:13:13
@@ -1591,6 +1591,8 @@ void LyXRC::set_font_norm_type()
font_norm_type = ISO_8859_6_8;
else if (font_norm == iso8859-9)
font_norm_type = ISO_8859_9;
+   else if (font_norm == iso8859-15)
+   font_norm_type = ISO_8859_15;
else
font_norm_type = OTHER_ENCODING;
 }
Index: src/lyxrc.h
===
RCS file: /cvs/lyx/lyx-devel/src/lyxrc.h,v
retrieving revision 1.48
diff -u -p -r1.48 lyxrc.h
--- src/lyxrc.h 2001/05/30 13:53:31 1.48
+++ src/lyxrc.h 2001/07/13 17:13:14
@@ -248,6 +248,8 @@ enum LyXRCTags {
///
ISO_8859_9,
///
+   ISO_8859_15,
+   ///
OTHER_ENCODING
};
///
Index: src/insets/ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/src/insets/ChangeLog,v
retrieving revision 1.125
diff -u -p -r1.125 ChangeLog
--- src/insets/ChangeLog2001/07/13 14:03:46 1.125
+++ src/insets/ChangeLog2001/07/13 17:13:14
@@ -1,3 +1,8 @@
+2001-07-13  Yves Bastide  [EMAIL PROTECTED]
+
+   * insetquotes.C (dispString): display french guillemets when using
+   ISO8859-15.
+
 2001-07-13  Angus Leeming  [EMAIL PROTECTED]
 
Consistent use of Lsstream.h:
Index: src/insets/insetquotes.C
===
RCS file: /cvs/lyx/lyx-devel/src/insets/insetquotes.C,v
retrieving revision 1.49
diff -u -p -r1.49 insetquotes.C
--- src/insets/insetquotes.C2001/07/06 15:57:53 1.49
+++ src/insets/insetquotes.C2001/07/13 17:13:14
@@ -152,7 +152,8 @@ string const InsetQuotes::dispString() c
if (times == InsetQuotes::DoubleQ)
disp += disp;
 
-   if (lyxrc.font_norm_type == LyXRC::ISO_8859_1)
+   if (lyxrc.font_norm_type == LyXRC::ISO_8859_1
+   || lyxrc.font_norm_type == LyXRC::ISO_8859_15)
if (disp == )
disp = '«';
else if (disp == )

Re: Patch: error message for unknown layouts

[Yves Bastide]

On Fri, Jul 13, 2001 at 09:24:20PM +0300, Dekel Tsur wrote:
 This patch creates an error dialog when reading a file that contains unknown
 layouts.
 Comments ?

Cool! This will prevent people like me manually re-diff-ing a thesis after
having forgotten to copy around some non-standard layouts.

-- 
Yves

Re: math font changes while moving

[Yves Bastide]

On Fri, Jul 13, 2001 at 03:57:36PM +0200, Andre Poenitz wrote:
[snip]
> How would we export that? \mbox{contents}?
[snip]

Perhaps another item for the bottom of your todo list: use AMS's \text
instead of \mbox.  It supports accented characters, among others...
(selected via validate()?)

> 
> Andre'
> 
> 
> -- 
> André Pönitz . [EMAIL PROTECTED]

-- 
Yves

Latin9

[Yves Bastide]

Hi,

this small patch adds a bit to the Latin9 support in LyX: with it, french
guillemets are displayed if the screen font is 8859-15.

It might also be worth adding with iso10646-1 ?..

Thanks,

-- 
Yves


Index: src/ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/src/ChangeLog,v
retrieving revision 1.230
diff -u -p -r1.230 ChangeLog
--- src/ChangeLog   2001/07/13 14:03:41 1.230
+++ src/ChangeLog   2001/07/13 17:13:13
@@ -1,3 +1,9 @@
+2001-07-13  Yves Bastide  <[EMAIL PROTECTED]>
+
+   * lyxrc.C (set_font_norm_type): recognise ISO_8859_15.
+
+   * lyxrc.h: added ISO_8859_15 to enum FontEncoding.
+
 2001-07-13  Angus Leeming  <[EMAIL PROTECTED]>
 
Consistent use of Lsstream.h:
Index: src/lyxrc.C
===
RCS file: /cvs/lyx/lyx-devel/src/lyxrc.C,v
retrieving revision 1.88
diff -u -p -r1.88 lyxrc.C
--- src/lyxrc.C 2001/06/29 11:54:38 1.88
+++ src/lyxrc.C 2001/07/13 17:13:13
@@ -1591,6 +1591,8 @@ void LyXRC::set_font_norm_type()
font_norm_type = ISO_8859_6_8;
else if (font_norm == "iso8859-9")
font_norm_type = ISO_8859_9;
+   else if (font_norm == "iso8859-15")
+   font_norm_type = ISO_8859_15;
else
font_norm_type = OTHER_ENCODING;
 }
Index: src/lyxrc.h
===
RCS file: /cvs/lyx/lyx-devel/src/lyxrc.h,v
retrieving revision 1.48
diff -u -p -r1.48 lyxrc.h
--- src/lyxrc.h 2001/05/30 13:53:31 1.48
+++ src/lyxrc.h 2001/07/13 17:13:14
@@ -248,6 +248,8 @@ enum LyXRCTags {
///
ISO_8859_9,
///
+   ISO_8859_15,
+   ///
OTHER_ENCODING
};
///
Index: src/insets/ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/src/insets/ChangeLog,v
retrieving revision 1.125
diff -u -p -r1.125 ChangeLog
--- src/insets/ChangeLog2001/07/13 14:03:46 1.125
+++ src/insets/ChangeLog2001/07/13 17:13:14
@@ -1,3 +1,8 @@
+2001-07-13  Yves Bastide  <[EMAIL PROTECTED]>
+
+   * insetquotes.C (dispString): display french guillemets when using
+   ISO8859-15.
+
 2001-07-13  Angus Leeming  <[EMAIL PROTECTED]>
 
Consistent use of Lsstream.h:
Index: src/insets/insetquotes.C
===
RCS file: /cvs/lyx/lyx-devel/src/insets/insetquotes.C,v
retrieving revision 1.49
diff -u -p -r1.49 insetquotes.C
--- src/insets/insetquotes.C2001/07/06 15:57:53 1.49
+++ src/insets/insetquotes.C2001/07/13 17:13:14
@@ -152,7 +152,8 @@ string const InsetQuotes::dispString() c
if (times == InsetQuotes::DoubleQ)
disp += disp;
 
-   if (lyxrc.font_norm_type == LyXRC::ISO_8859_1)
+   if (lyxrc.font_norm_type == LyXRC::ISO_8859_1
+   || lyxrc.font_norm_type == LyXRC::ISO_8859_15)
if (disp == "<<")
disp = '«';
else if (disp == ">>")

Re: Patch: error message for unknown layouts

[Yves Bastide]

On Fri, Jul 13, 2001 at 09:24:20PM +0300, Dekel Tsur wrote:
> This patch creates an error dialog when reading a file that contains unknown
> layouts.
> Comments ?

Cool! This will prevent people like me manually re-diff-ing a thesis after
having forgotten to copy around some non-standard layouts.

-- 
Yves

Patch LyX 1.1.6fix3: use frenchb guillemets

[Yves Bastide]

Hi,

Here's a proposed patch to use frenchb's guillemets \og and \fg (which
have proper spacing) when using frenchb.  The current code does it only
when fontenc != T1 -- not frequent among French writers (:

(This patch is for 1.1.6; I can prepare another for -devel if accepted.)

-- 
Yves








Index: ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/ChangeLog,v
retrieving revision 1.757.2.89
diff -u -p -r1.757.2.89 ChangeLog
--- ChangeLog   2001/06/18 16:03:24 1.757.2.89
+++ ChangeLog   2001/06/19 17:21:31
@@ -1,3 +1,8 @@
+2001-06-19  Yves Bastide  [EMAIL PROTECTED]
+
+   * src/insets/insetquotes.C (InsetQuotes::Latex): fix frenchb
+   french guillemets use.
+
 2001-06-18  Jean-Marc Lasgouttes  [EMAIL PROTECTED]
 
* lib/tex/cv.cls:
Index: src/insets/insetquotes.C
===
RCS file: /cvs/lyx/lyx-devel/src/insets/insetquotes.C,v
retrieving revision 1.40.2.2
diff -u -p -r1.40.2.2 insetquotes.C
--- src/insets/insetquotes.C2001/05/14 16:44:11 1.40.2.2
+++ src/insets/insetquotes.C2001/06/19 17:21:32
@@ -235,8 +235,15 @@ int InsetQuotes::Latex(Buffer const * bu
string const doclang = buf-GetLanguage()-lang();
int quoteind = quote_index[side][language];
string qstr;
-   
-   if (lyxrc.fontenc == T1) {
+
+   if (language == InsetQuotes::FrenchQ 
+ times == InsetQuotes::DoubleQ
+ doclang == frenchb) {
+   if (side == InsetQuotes::LeftQ) 
+   qstr = \\og{};
+   else 
+   qstr =  \\fg{};
+   } else if (lyxrc.fontenc == T1) {
qstr = latex_quote_t1[times][quoteind];
 #ifdef DO_USE_DEFAULT_LANGUAGE
} else if (doclang == default) {
@@ -244,13 +251,6 @@ int InsetQuotes::Latex(Buffer const * bu
} else if (!use_babel) {
 #endif
qstr = latex_quote_ot1[times][quoteind];
-   } else if (language == InsetQuotes::FrenchQ 
- times == InsetQuotes::DoubleQ
- doclang == frenchb) {
-   if (side == InsetQuotes::LeftQ) 
-   qstr = \\og{};
-   else 
-   qstr =  \\fg{};
} else 
qstr = latex_quote_babel[times][quoteind];
 

Patch LyX 1.1.6fix3: use frenchb guillemets

[Yves Bastide]

Hi,

Here's a proposed patch to use frenchb's guillemets \og and \fg (which
have proper spacing) when using frenchb.  The current code does it only
when fontenc != T1 -- not frequent among French writers (:

(This patch is for 1.1.6; I can prepare another for -devel if accepted.)

-- 
Yves








Index: ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/ChangeLog,v
retrieving revision 1.757.2.89
diff -u -p -r1.757.2.89 ChangeLog
--- ChangeLog   2001/06/18 16:03:24 1.757.2.89
+++ ChangeLog   2001/06/19 17:21:31
@@ -1,3 +1,8 @@
+2001-06-19  Yves Bastide  <[EMAIL PROTECTED]>
+
+   * src/insets/insetquotes.C (InsetQuotes::Latex): fix frenchb
+   french guillemets use.
+
 2001-06-18  Jean-Marc Lasgouttes  <[EMAIL PROTECTED]>
 
* lib/tex/cv.cls:
Index: src/insets/insetquotes.C
===
RCS file: /cvs/lyx/lyx-devel/src/insets/insetquotes.C,v
retrieving revision 1.40.2.2
diff -u -p -r1.40.2.2 insetquotes.C
--- src/insets/insetquotes.C2001/05/14 16:44:11 1.40.2.2
+++ src/insets/insetquotes.C2001/06/19 17:21:32
@@ -235,8 +235,15 @@ int InsetQuotes::Latex(Buffer const * bu
string const doclang = buf->GetLanguage()->lang();
int quoteind = quote_index[side][language];
string qstr;
-   
-   if (lyxrc.fontenc == "T1") {
+
+   if (language == InsetQuotes::FrenchQ 
+&& times == InsetQuotes::DoubleQ
+&& doclang == "frenchb") {
+   if (side == InsetQuotes::LeftQ) 
+   qstr = "\\og{}";
+   else 
+   qstr = " \\fg{}";
+   } else if (lyxrc.fontenc == "T1") {
qstr = latex_quote_t1[times][quoteind];
 #ifdef DO_USE_DEFAULT_LANGUAGE
} else if (doclang == "default") {
@@ -244,13 +251,6 @@ int InsetQuotes::Latex(Buffer const * bu
} else if (!use_babel) {
 #endif
qstr = latex_quote_ot1[times][quoteind];
-   } else if (language == InsetQuotes::FrenchQ 
-&& times == InsetQuotes::DoubleQ
-&& doclang == "frenchb") {
-   if (side == InsetQuotes::LeftQ) 
-   qstr = "\\og{}";
-   else 
-   qstr = " \\fg{}";
} else 
qstr = latex_quote_babel[times][quoteind];
 

Re: LyX 1.1.6fix3 and namespaces

[Yves Bastide]

On Fri, Jun 08, 2001 at 04:36:10PM +0200, Jean-Marc Lasgouttes wrote:
  Yves == Yves Bastide [EMAIL PROTECTED] writes:
 
 Yves Here's a patch; I finally didn't try to go and test the kde and
 Yves gnome frontends, since the versions of the libraries I have are
 Yves themselves to-be-cleaned.
 
 I do not like much the lstring.h solution... How come the main branch
 does not have this problem? Same goes for the separation of statements
 in paragraph.C...

Hmm... Yes, I should have looked better.
About lstring: lstring.h doesn't include cstring in the main branch, and
use the #ifndef CXX_GLOBAL_CSTD trick (just as Lars told me %)
paragraph.C: s/os.tellp()/int(os.tellp())/

 
 JMarc

-- 
Yves

LyX 1.1.6fix3 and namespaces, take two

[Yves Bastide]

Here is a second patch for building 1.1.6fix with gcc 3.0.  This one
should be less bad :)

-- 
Yves

 std-try2.patch.gz

Re: LyX 1.1.6fix3 and namespaces

[Yves Bastide]

On Fri, Jun 08, 2001 at 04:36:10PM +0200, Jean-Marc Lasgouttes wrote:
> >>>>> "Yves" == Yves Bastide <[EMAIL PROTECTED]> writes:
> 
> Yves> Here's a patch; I finally didn't try to go and test the kde and
> Yves> gnome frontends, since the versions of the libraries I have are
> Yves> themselves to-be-cleaned.
> 
> I do not like much the lstring.h solution... How come the main branch
> does not have this problem? Same goes for the separation of statements
> in paragraph.C...

Hmm... Yes, I should have looked better.
About lstring: lstring.h doesn't include  in the main branch, and
use the #ifndef CXX_GLOBAL_CSTD trick (just as Lars told me %)
paragraph.C: s/os.tellp()/int(os.tellp())/

> 
> JMarc

-- 
Yves

LyX 1.1.6fix3 and namespaces, take two

[Yves Bastide]

Here is a second patch for building 1.1.6fix with gcc 3.0.  This one
should be less bad :)

-- 
Yves

 std-try2.patch.gz

Re: Towards LyX 1.1.6fix3 (status update #1)

[Yves Bastide]

On Wed, Jun 06, 2001 at 09:37:24PM +0200, Herbert Voss wrote:
 Dekel Tsur wrote:
  
  On Wed, Jun 06, 2001 at 04:57:19PM +0200, Jean-Marc Lasgouttes wrote:
  
   - the aapaper class has been renamed to aa and updated
  
  You should add to the announcement a big warning that the \textclass in
  old aa documents should changed be using a text editor/script.
 
 let the old aapaper in the layout-dir too, until 1.2.0
 comes out.
 aa and aapaper for a limited time may be okay.

This looks like the cases where LyX reports big problems on lyxerr (i.e.
most certainly in ~/.xsession_error or somesuch) instead of displaying a
message box.
[I've been bitten in my thesis, where a personalized layout included other
personalized ones--that I hadn't recopied in the appropriate ~/.lyx*: I
noticed I had lost theorems and such just before the final print :-)]

 
 Herbert
 
 -- 
 http://www.educat.hu-berlin.de/~voss/lyx/

-- 
Yves

LyX 1.1.6fix3 and namespaces

[Yves Bastide]

It seems that another number of std:: or using std:: are needed to compile
LyX 1.1.6 with GCC 3.0 or other modern compilers.

I guess that, in .C files, the preferred way is to use

#ifndef CXX_GLOBAL_CSTD
using std::strlen;
...
#endif

But what about header files?  Is The Right Thing, such as

--- src/font.h  2000/09/27 18:13:29 1.6
+++ src/font.h  2001/06/07 10:10:11
@@ -61,7 +61,7 @@ struct lyxfont {
///
static
int width(char const * s, LyXFont const  f) {
-   return width(s, strlen(s), f);
+   return width(s, std::strlen(s), f);
}
///
static

acceptable for older compilers?

Thanks,

Yves

Re: [PATCH] remove KDE frontend

[Yves Bastide]

On Thu, Jun 07, 2001 at 04:38:01PM +0200, Jean-Marc Lasgouttes wrote:
  John == John Levon [EMAIL PROTECTED] writes:
 
 John --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii
 John Content-Disposition: inline
 
 John Things are worse than I thought. My previously reported bug with
 John autogen.sh and the broken library thing is /not/ due to the
 John attached patch.
 
 John I currently can't build lyx as a result. Can someone please look
 John into the problem ? Am I the only one who gets the problem with
 John autogen.sh ?
 
 Did you update libtool and automake? Note that you should not update
 autoconf to 2.50 yet.
 

About autoconf 2.50: I've prepared a patch with compatibility macros, but
it needs to be cleaned up a bit.

[snip]

 JMarc

-- 
Yves

Re: LyX 1.1.6fix3 and namespaces

[Yves Bastide]

On Thu, Jun 07, 2001 at 02:36:17PM +0200, Jean-Marc Lasgouttes wrote:
  Yves == Yves Bastide [EMAIL PROTECTED] writes:
 
 Yves It seems that another number of std:: or using std:: are needed
 Yves to compile LyX 1.1.6 with GCC 3.0 or other modern compilers.
 
 Yes, a patch to do that would be welcome.
 

OK, I just did one; now checking if there are no errors with 2.95 (since I
don't have other supported compilers).  The diff is ~1000 lines, trivial.

The only problem I found is with C headers including string.h.  This
header injects strlen et al. in the global namespace, and doing
using std::strlen after is an error for GCC 3.0 (didn't check what the
standard says).  So I put
#include support/lstrings.h
before
#include FORMS_H_LOCATION
in a number of files.  This is a hack: lstring.h includes cstring, and
string.h is ignored.
(In other cases, I directly included cstring...)

Hm, not attaching the patch right now: I didn't fix other frontends than
xforms

[snip]
 
 JMarc

-- 
Yves

Re: LyX 1.1.6fix3 and namespaces

[Yves Bastide]

On Thu, Jun 07, 2001 at 07:23:08PM +0200, Lars Gullik Bjønnes wrote:
 [EMAIL PROTECTED] (Yves Bastide) writes:
[about patches for gcc 3.0]
 
 I wonder why you have to change anything at all... I am compilig with
 gcc 3.0 all the and have commited all the changes I needed to
 compile...

Are you talking about -devel or the 1_1_6 branch?

 
 -- 
   Lgb

-- 
Yves

Re: LyX 1.1.6fix3 and namespaces

[Yves Bastide]

On Thu, Jun 07, 2001 at 08:01:38PM +0200, Lars Gullik Bjønnes wrote:
 [EMAIL PROTECTED] (Yves Bastide) writes:
 
 | On Thu, Jun 07, 2001 at 07:23:08PM +0200, Lars Gullik Bjønnes wrote:
 |  [EMAIL PROTECTED] (Yves Bastide) writes:
 | [about patches for gcc 3.0]
 |  
 |  I wonder why you have to change anything at all... I am compilig with
 |  gcc 3.0 all the and have commited all the changes I needed to
 |  compile...
 | 
 | Are you talking about -devel or the 1_1_6 branch?
 
 devel...
 
 and I figure you are taling bout the 1.1.6 branch... ok

yup

Here's a patch; I finally didn't try to go and test the kde and gnome
frontends, since the versions of the libraries I have are themselves
to-be-cleaned.

 
 -- 
   Lgb

-- 
Yves

 std-1.1.6.diff.gz