Re: [PATCHES 13x, 14x] Typo in os.C?
On Tue, Dec 14, 2004 at 02:26:54PM +0100, Jean-Marc Lasgouttes wrote: > What is special about cygwin, except from the fact that it needs a way > to translate file names to/from dos conventions? There is no such need. cygwin handles both naming conventions fairly well. Andre'
Re: What to do with nlink_t?
On Wed, Dec 15, 2004 at 02:40:53PM +, Angus Leeming wrote: > Nonetheless, the question remains. Is this the way to go, or should I > change the FileInfo function declaration to return a lyx::size_type? I'd prefer std::size_t. Andre'
Re: Native and GPLed Win32 version
On Wed, Dec 15, 2004 at 11:24:12AM +0100, Asger Kunuk Ottar Alstrup wrote: > How well does a native Qt Win32 work? It works to the same degree as it works on *nix. I am not sure where you'd put that on an absolute scale, but it's certainly ok for LyX. Andre'
Re: LyX + MinGW + MinSYS + GPLed QT/Win32 --- success!
On Tue, Dec 14, 2004 at 12:48:40PM +0100, Jean-Marc Lasgouttes wrote: > Ruurd> It´s already included in mingw, not in MSVC. > > Ahh, OK. I guess it would be a good idea to incorporate patches for > mingw first, and then msvc. Is that doable? Haws anybody ever compiled LyX wuth msvc? Ruurd? How did do get past ./configure? Created a .vcproj? Andre'
Re: [PATCH 13x, 14x] OS abstraction of "HOME" and the null device
On Wed, Dec 15, 2004 at 01:53:22PM +, Angus Leeming wrote: > > I don't think so. Either you put it in \windows\system (I think) where > > everybody can find it, or, > > Ok. Thanks. What about the header files? (What is normally done?) You don't usually distribute header files. So for your own development, put %QTDIR% in your path and for distribution put qt333.dll in the lyx dir or link statically. Andre'
Re: [PATCH 13x, 14x] OS abstraction of "HOME" and the null device
On Wed, Dec 15, 2004 at 11:21:17AM +, Angus Leeming wrote: > Interesting. I found that I had to start lyx from the /home/Angus/qt3/lib > directory (so that qt333.dll was found; I could have changed my PATH > variable but only found that out later) as > > lyx -sysdir /home/Angus/lyx-13x/lib \ > -userdir /home/Angus/lyx-13x/build-qt/lib > > so that chkconfig.ltx and textclass.lst could be found. I guess that this > reinforces your points above. Onve you use Qt on Win regularly, it's a good idea to have QTDIR in your path anyway. Andre'
[patch] forceDefaultParagraphs
This patch gets rid of Paragraph::forceDefaultParagraphs (the second user of
Paragraph::inInset)
The replacement is to call InsetBase::forceDefaultParagraph when the inset
is available, add to add an aditional flag to OutputParams to be passed
down in latex() methods, when the inset is not available.
The patch is not as straightforward as the last one, as some of the
functionality seemed to be disabled in CVS. [ For instance,
Paragraph::forceDefaultParagraphs called inInset().forceDefaultParagraphs.
In the case of tabulars, this is the InsetText cell, that doesn't have the
information to handle that (and defaults to false). The information is yet
another level up, in InsetTabular. ]
Comments?
? autobreak.diff
? force.diff
? output_latex.C-save
? output_latex.h-save
Index: lyxfunc.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxfunc.C,v
retrieving revision 1.635
diff -u -p -r1.635 lyxfunc.C
--- lyxfunc.C 6 Dec 2004 13:03:38 - 1.635
+++ lyxfunc.C 17 Dec 2004 20:25:46 -
@@ -366,7 +366,7 @@ FuncStatus LyXFunc::getStatus(FuncReques
case LFUN_LAYOUT:
case LFUN_LAYOUT_PARAGRAPH:
- enable = !cur.inset().forceDefaultParagraphs(&cur.inset());
+ enable = !cur.inset().forceDefaultParagraphs(cur.idx());
break;
case LFUN_VC_REGISTER:
Index: output_latex.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/output_latex.C,v
retrieving revision 1.18
diff -u -p -r1.18 output_latex.C
--- output_latex.C 26 Nov 2004 14:52:52 - 1.18
+++ output_latex.C 17 Dec 2004 20:25:46 -
@@ -228,14 +228,14 @@ TeXOnePar(Buffer const & buf,
bool further_blank_line = false;
LyXLayout_ptr style;
+ OutputParams runparams = runparams_in;
// In an an inset with unlimited length (all in one row),
// force layout to default
- if (!pit->forceDefaultParagraphs())
+ if (!runparams.forceDefaultParagraphs)
style = pit->layout();
else
style = bparams.getLyXTextClass().defaultLayout();
- OutputParams runparams = runparams_in;
runparams.moving_arg |= style->needprotect;
Language const * language = pit->getParLanguage(bparams);
@@ -282,7 +282,7 @@ TeXOnePar(Buffer const & buf,
// In an an inset with unlimited length (all in one row),
// don't allow any special options in the paragraph
- if (!pit->forceDefaultParagraphs()) {
+ if (!runparams.forceDefaultParagraphs) {
if (pit->params().startOfAppendix()) {
os << "\\appendix\n";
texrow.newline();
@@ -399,7 +399,7 @@ paragraphs);
}
}
- if (!pit->forceDefaultParagraphs()) {
+ if (!runparams.forceDefaultParagraphs) {
further_blank_line = false;
if (further_blank_line) {
@@ -416,7 +416,7 @@ paragraphs);
}
}
- if (boost::next(pit) == const_cast(paragraphs).end()
+ if (boost::next(pit) == paragraphs.end()
&& language->babel() != doc_language->babel()) {
// Since \selectlanguage write the language to the aux file,
// we need to reset the language at the end of footnote or
@@ -470,7 +470,7 @@ void latexParagraphs(Buffer const & buf,
// length (all in one row) if that is true then we don't allow
// any special options in the paragraph and also we don't allow
// any environment other then "Standard" to be valid!
- if (!par->forceDefaultParagraphs()) {
+ if (!runparams.forceDefaultParagraphs) {
LyXLayout_ptr const & layout = par->layout();
if (layout->intitle) {
@@ -502,16 +502,16 @@ void latexParagraphs(Buffer const & buf,
}
if (layout->is_environment) {
-par = TeXOnePar(buf, paragraphs, par, os, texrow,
-runparams, everypar);
+par = TeXOnePar(buf, paragraphs, par, os,
+ texrow, runparams, everypar);
} else if (layout->isEnvironment() ||
!par->params().leftIndent().zero())
{
par = TeXEnvironment(buf, paragraphs, par, os,
texrow, runparams);
} else {
-par = TeXOnePar(buf, paragraphs, par, os, texrow,
-runparams, everypar);
+par = TeXOnePar(buf, paragraphs, par, os,
+ texrow, runparams, everypar);
}
} else {
par = TeXOnePar(buf, paragraphs, par, os, texrow,
Index: output_latex.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/output_latex.h,v
retrieving revision 1.2
diff -u -p -r1.2 output_latex.h
--- output_latex.h 25 Mar 2004 09:16:19 - 1.2
+++ output_latex.h 17 Dec 2004 20:25:46 -
@@ -19,7 +19,6 @@ class OutputParams;
class ParagraphList;
class TexRow;
-/// Just a wrapper for the method below, first creating the ofstream.
void latexParagraphs(Buffer const & buf,
ParagraphList const & paragraphs,
Index: outputparams.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/outputparams.C,v
retrieving revision 1.3
diff -u -p -r1.3 outputparams.C
--- outputparams.C 2 Nov 2004 11:25:16 - 1.3
Re: Questions about path conversions
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> No, Jean-Marc. This does not mean we should drop support for Angus> cygwin. Come on, drop did not mean drop, just forget about dos paths for cygwin. I do not see what use a cygwin port can have, except behave like an X/unix app. JMarc
Re: Questions about path conversions
Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | All our pain comes from this filesystem nonsense and we have to address
> | that anyway for Windows. Once it has been addressed (means store a path
> | by passing it through internal_path and hand it to the outside world
> | after passing this stored path through external_path) then the cost of
> | supporting cygwin is neglibible.
>
> Hmm... have I said boost::filesystem lately?
I refer you to a previous section of the mail you are replying to:
The way that Boost.Filesystem does it is better I think. It
splits the path into two separate entities:
path = root relative-path
where root:
root = root-name root-directory
(So, on unix root-name is empty and on windows it's 'C:' etc)
relative-path = path-element ( '/' path-element)* '/'?
So then all transformations *'\' -> '/') occur to relative-path only.
I think that there are real advantages to moving to the use of
Boost.Filesystem, just not now ;-)
Incidentally, whilst the conceptualisation is great, the implementation of
Boost.Filesystem falls over on cygwin where both Posix and Windows paths
are in use. So we'll still need
namespace fs = boost::filesystem;
fs::path const internal_path(std::string const & path_str)
{
#if defined (__CYGWIN__) || defined(__CYGWIN32__)
if (fs::windows_name(path_str))
return fs::path(subst(path_str, '\\', '/'));
return fs::path(path_str);
#elif defined (_WIN32)
if (fs::windows_name(path_str))
return fs::path(path_str);
return fs::path();
#elif defined (__EMX__)
//We'll have to write our own code here???
#else // POSIX
return fs::path(path_str, fs::no_check);
#endif
}
Similarly, we'll still need external_path().
No, Jean-Marc. This does not mean we should drop support for cygwin.
--
Angus
Re: license for documentation?
On Fri, 17 Dec 2004, Asger Kunuk Ottar Alstrup wrote: > On Tue, 14 Dec 2004, Jeremy C. Reed wrote: > > > Does the COPYING file apply to all the doc/ documentation that don't have > > any license in them? > > > > For example, I don't see any republishing or reuse license for > > lib/doc/Customization.lyx. > > It is a good question. When the documentation was written, the concept of > licenses for documentation was not really crystalised yet. So, the > question was never really asked and thus never answered. I believe that a > fair interpretation of intent is that the documentation is GPL. > > > I want to test a print-on-demand service. I want to submit the LyX > > documentation in a single PDF format for a single book. Is this okay? > > I belive that would be ok, but you might try to ask John Weiss who is the > main author of the documentation, and as such he would be the main > copyright holder, although many, many people have contributed, including > Matthias Ettrich who wrote the initial documentation on which everything > is based. I believe he would be the person that defined the original > license, although it was implicit. See Credits for more info on > contributors. Okay, I emailed John Weiss. Also, I see the CREDITS lists a "documentation maintainer" (and that John is the "editor of the documentation project"). > My personal oppinion is that a printed version of LyX documentation would > be a very welcome contribution to the community. A book with a CD in it > would definately be nice, especially if some of the profits were donated > to the LyX meeting sponsoring fund. I'd be glad to help set this up. And I'll make sure that some of the profits are sent to the LyX project. As for now though, I just want to use it for some quick tests of the printer's service. I just joined the lyx-docs list. I guess this discussion should be moved over there. Thanks, Jeremy C. Reed BSD News, BSD tutorials, BSD links http://www.bsdnewsletter.com/
Re: [patch] encoding error
Martin Vermeer wrote: > Ok, here is the complete patch then. To go in presently, under general > cheering. And here's what you forgot. Committing now since it breaks compiling. Jürgen Index: Makefile.am === RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/Makefile.am,v retrieving revision 1.67 diff -u -r1.67 Makefile.am --- Makefile.am 4 Nov 2004 16:40:10 - 1.67 +++ Makefile.am 17 Dec 2004 16:06:11 - @@ -601,8 +601,8 @@ images/math/surd.xpm \ images/math/swarrow.xpm \ images/math/tau.xpm \ - images/math/textrm_0.xpm \ - images/math/textrm_A.xpm \ + images/math/textrm_Oe.xpm \ + images/math/textrm_AA.xpm \ images/math/therefore.xpm \ images/math/theta.xpm \ images/math/theta2.xpm \
Re: [patch] autoBreakRows
Jean-Marc Lasgouttes wrote: > OK, I was just joking. Everybody know we do not understand the code we > are manipulating... > > But be prepared next time! Fiuuu... Close enough! Ahem I mean... sure thing sir! Alfredo
Re: [patch] autoBreakRows
> "Alfredo" == Alfredo Braunstein <[EMAIL PROTECTED]> writes: Alfredo> C'mon it's not fair!... don't make me go look what is it! ;-) OK, I was just joking. Everybody know we do not understand the code we are manipulating... But be prepared next time! JMarc
Re: Questions about path conversions
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> All our pain comes from this filesystem nonsense and we have to Angus> address that anyway for Windows. Once it has been addressed Angus> (means store a path by passing it through internal_path and Angus> hand it to the outside world after passing this stored path Angus> through external_path) then the cost of supporting cygwin is Angus> neglibible. What I mean is a bit different: I think that a cygwin version of LyX should behave like a posix app. Do cygwin ports like bash or sed support DOS-style file names? For people who want the DOS file names, we'll have the mingw version. Does it make sense? JMarc
Re: [patch] autoBreakRows
> Alfredo> Didn't study it too much ;-) The patch is a functional > Alfredo> identity ... > > Naughty boy... How embarrassing mister... I didn't prepare my lesson. > Alfredo> It seems that it's basically used to forbid multiple > Alfredo> paragraphs in table cells. > > Hmm. C'mon it's not fair!... don't make me go look what is it! ;-) Alfredo
Re: [patch] autoBreakRows
Angus Leeming wrote: > Alfredo Braunstein wrote: > >> The following patch gets rid of Paragraph::autoBreakRows(), one of the >> two users of Paragraph::inInset(). > > Doesn't look like two to me: Dammit you are right, they are 3 ;-) > $ grep -r inInset . this just goes away: > CutAndPaste.C: tmpbuf->setInsetOwner(pars[pit].inInset()); This is user 1: > text2.C:in = pars_[tmppit].inInset(); This is user 2 (autobreakrows): > paragraph.C:return inInset() && > inInset()->forceDefaultParagraphs(inInset()); this is user 3: > paragraph.C:return inInset() && > static_cast(inInset())->getAutoBreakRows(); This just goes away > paragraph_funcs.C: tmp->setInsetOwner(par.inInset()); Unrelated: > frontends/controllers/ControlParagraph.C:bool ControlParagraph::inInset() > const > frontends/controllers/ControlParagraph.h: bool inInset() const; > frontends/controllers/ControlVSpace.h: bool inInset() const; > > It looks to me like the controller functions are never actually used > either, so maybe you can cull these too? Maybe, but these are different inInset()s... I'm mainly concerned about Paragraph::inInset() which is a dirty backpointerage. I think it's a good opportunity because it's asserting now somewhere... >> Getting rid of inInset() is a worthy >> goal in itself, and would even solve some reported crashes. >> >> I've moved the autoBreakRows_ bool from InsetText to LyXText to make it >> available to some LyXText member functions, but otherwise the patch is >> straightforward. Ok? > > Looks like simpler logic too. I think so also. Alfredo
Re: Questions about path conversions
Angus Leeming <[EMAIL PROTECTED]> writes: | All our pain comes from this filesystem nonsense and we have to address | that anyway for Windows. Once it has been addressed (means store a path by | passing it through internal_path and hand it to the outside world after | passing this stored path through external_path) then the cost of | supporting cygwin is neglibible. Hmm... have I said boost::filesystem lately? -- Lgb
Re: Questions about path conversions
Jean-Marc Lasgouttes wrote: >> "Kuba" == Kuba Ober <[EMAIL PROTECTED]> >> writes: > >>> I think we should probably use only internal_path and only work >>> inside LyX with paths which use / as separator. Of course, a second >>> problem is that win32 names will retain drive numbers, but stuff in >>> filetools should take care of that. > > Kuba> What about always using unix paths internally, and simply > Kuba> translating C:\dir\x into /C:/dir/x ? > > And how does c:file.txt get translated? Windows has a strange notion > of what an absolute path is. > > Otherwise, it looks like a good idea. No. Let's not get involved in this. Pleease. The correct strategy IMO is to move to the use of Boost.Filesystem or some other, external library to handle these issues for us. Meanwhile, let's keep any changes as simple as possible. -- Angus
Re: [patch] autoBreakRows
> "Alfredo" == Alfredo Braunstein <[EMAIL PROTECTED]> writes: Alfredo> Didn't study it too much ;-) The patch is a functional Alfredo> identity ... Naughty boy... Alfredo> It seems that it's basically used to forbid multiple Alfredo> paragraphs in table cells. Hmm. JMarc
Re: Questions about path conversions
On piÄtek 17 grudzieÅ 2004 10:16 am, Jean-Marc Lasgouttes wrote: > > "Kuba" == Kuba Ober <[EMAIL PROTECTED]> writes: > >> > >> I think we should probably use only internal_path and only work > >> inside LyX with paths which use / as separator. Of course, a second > >> problem is that win32 names will retain drive numbers, but stuff in > >> filetools should take care of that. > > Kuba> What about always using unix paths internally, and simply > Kuba> translating C:\dir\x into /C:/dir/x ? > > And how does c:file.txt get translated? Windows has a strange notion > of what an absolute path is. That is not an absolute path, but a relative path on a given drive :) I never explicitly supported "relative path on gien drive", namely because in graphical windows environment it never makes any sense -- i.e. in the GUI you'd never type anything like that. For any other use, it's for input only anyway. So, for OS-to-unix translation, you simply always expand the OS path with full, absolute path. Only that makes any sense. In fact, I always convert any OS path to absolute path before unix-izing it, so I've never faced the problem directly. c:file.txt -> c:\currentdir\file.txt -> /c:/currentdir/file.txt Now, if you have stuff where relative paths are useful (e.g. project-relative), then those will never have a drive in them. If they do, they auomatically are treated like absolute paths and if e.g. the input box has a validator, it should reject such a path. Kuba
Re: Questions about path conversions
Jean-Marc Lasgouttes wrote: > Angus> 2. Why don't we need to do something similar for Windows? Is it > Angus> because we plan to store the paths internally as C:/Windows/Bar > Angus> and so don't have to worry about this mount table nonsense? > > It is because we do not know how to do it and we are forced to handle > this colon :( Not quite true. The cygwin way is false too in that /c/foo is an arbitrary invention. The way that Boost.Filesystem does it is better I think. It splits the path into two separate entities: path = root relative-path where root: root = root-name root-directory (So, on unix root-name is empty and on windows it's 'C:' etc) relative-path = path-element ( '/' path-element)* '/'? So then all transformations *'\' -> '/') occur to relative-path only. I think that there are real advantages to moving to the use of Boost.Filesystem, just not now ;-) Incidentally, GetEnv returning a string is just plain crazy. It should return a vector. But I digress ;-) > Different idea: (almost) drop support for cygwin! > > Here is an idea I had while reading your message: we could also decide > that the cygwin version of LyX is a posix-like one, and that it can > only deal with unix-paths. This means that most special cygwin code > will go away, and that LyX/Cygwin will be basically LyX/Unix. > > People who want to interact with native windows apps will then use the > mingw (or msvc) version, which will always use windows paths. > > Does it look like an idea? I think it makes matters clearer. All our pain comes from this filesystem nonsense and we have to address that anyway for Windows. Once it has been addressed (means store a path by passing it through internal_path and hand it to the outside world after passing this stored path through external_path) then the cost of supporting cygwin is neglibible. I think that if we can isolate the cygwin-specific stuff to os_cygwin.C (as, clearly we can because LyX works on cygwin now) then there is no need to drop support for cygwin because it is painless to retain support. So, you see, I'm am less radical than you ;-) -- Angus
Re: [patch] autoBreakRows
Alfredo Braunstein wrote: > The following patch gets rid of Paragraph::autoBreakRows(), one of the > two users of Paragraph::inInset(). Doesn't look like two to me: $ grep -r inInset . CutAndPaste.C: tmpbuf->setInsetOwner(pars[pit].inInset()); text2.C:in = pars_[tmppit].inInset(); paragraph.C:return inInset() && inInset()->forceDefaultParagraphs(inInset()); paragraph.C:return inInset() && static_cast(inInset())->getAutoBreakRows(); paragraph_funcs.C: tmp->setInsetOwner(par.inInset()); frontends/controllers/ControlParagraph.C:bool ControlParagraph::inInset() const frontends/controllers/ControlParagraph.h: bool inInset() const; frontends/controllers/ControlVSpace.h: bool inInset() const; It looks to me like the controller functions are never actually used either, so maybe you can cull these too? > Getting rid of inInset() is a worthy > goal in itself, and would even solve some reported crashes. > > I've moved the autoBreakRows_ bool from InsetText to LyXText to make it > available to some LyXText member functions, but otherwise the patch is > straightforward. Ok? Looks like simpler logic too. -- Angus
Re: [patch] autoBreakRows
Jean-Marc Lasgouttes wrote: >> "Alfredo" == Alfredo Braunstein >> <[EMAIL PROTECTED]> writes: > > Alfredo> The following patch gets rid of Paragraph::autoBreakRows(), > Alfredo> one of the two users of Paragraph::inInset(). Getting rid of > Alfredo> inInset() is a worthy goal in itself, and would even solve > Alfredo> some reported crashes. > > Could you remind me what autoBreakRows does? Didn't study it too much ;-) The patch is a functional identity ... It seems that it's basically used to forbid multiple paragraphs in table cells. Alfredo
Re: Questions about path conversions
On piÄtek 17 grudzieÅ 2004 10:14 am, Kuba Ober wrote: > > I think we should probably use only internal_path and only work inside > > LyX with paths which use / as separator. Of course, a second problem > > is that win32 names will retain drive numbers, but stuff in filetools > > should take care of that. > > What about always using unix paths internally, and simply translating > C:\dir\x into /C:/dir/x ? Alternatively, if you don't envision people having one-letter-named servers in UNC paths, you can drop the ':'. In my implementation I've left the ':' just in case. Kuba
Re: Questions about path conversions
> "Kuba" == Kuba Ober <[EMAIL PROTECTED]> writes: >> I think we should probably use only internal_path and only work >> inside LyX with paths which use / as separator. Of course, a second >> problem is that win32 names will retain drive numbers, but stuff in >> filetools should take care of that. Kuba> What about always using unix paths internally, and simply Kuba> translating C:\dir\x into /C:/dir/x ? And how does c:file.txt get translated? Windows has a strange notion of what an absolute path is. Otherwise, it looks like a good idea. JMarc
Re: [patch] autoBreakRows
> "Alfredo" == Alfredo Braunstein <[EMAIL PROTECTED]> writes: Alfredo> The following patch gets rid of Paragraph::autoBreakRows(), Alfredo> one of the two users of Paragraph::inInset(). Getting rid of Alfredo> inInset() is a worthy goal in itself, and would even solve Alfredo> some reported crashes. Could you remind me what autoBreakRows does? JMarc
Re: Questions about path conversions
> I think we should probably use only internal_path and only work inside > LyX with paths which use / as separator. Of course, a second problem > is that win32 names will retain drive numbers, but stuff in filetools > should take care of that. What about always using unix paths internally, and simply translating C:\dir\x into /C:/dir/x ? I.e. the os interface would always present unix paths to the application, and would always take unix paths from the application too? In the cross-platform projects that I work on that's what I always do. When paths are presented to the user, they are always presented in the OS form, so that all UI stuff uses something that looks native on given OS. But those OS-dependent paths are never stored anywhere, they exist only temporarily. As far as UNC paths go, I translate \\server\blublah into /server/blublah So, to translate those back to Windows paths, if the beginning matches "/[a-zA-Z]:" the first slash is dropped, and if the beginning matches "/[^:/]+" then the first slash is replaced with \\ Cheers, Kuba Ober
[patch] autoBreakRows
The following patch gets rid of Paragraph::autoBreakRows(), one of the two
users of Paragraph::inInset(). Getting rid of inInset() is a worthy goal in
itself, and would even solve some reported crashes.
I've moved the autoBreakRows_ bool from InsetText to LyXText to make it
available to some LyXText member functions, but otherwise the patch is
straightforward. Ok?
Regards, Alfredo
? alldevel.diff
? output_latex.C-save
? output_latex.h-save
Index: buffer.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/buffer.C,v
retrieving revision 1.595
diff -u -p -r1.595 buffer.C
--- buffer.C 3 Dec 2004 18:39:49 - 1.595
+++ buffer.C 17 Dec 2004 14:55:09 -
@@ -474,7 +474,7 @@ bool Buffer::readDocument(LyXLex & lex)
// needed to insert the selection
void Buffer::insertStringAsLines(ParagraphList & pars,
pit_type & par, pos_type & pos,
- LyXFont const & fn, string const & str)
+ LyXFont const & fn, string const & str, bool autobreakrows)
{
LyXLayout_ptr const & layout = pars[par].layout();
@@ -483,7 +483,6 @@ void Buffer::insertStringAsLines(Paragra
pars[par].checkInsertChar(font);
// insert the string, don't insert doublespace
bool space_inserted = true;
- bool autobreakrows = pars[par].autoBreakRows();
for (string::const_iterator cit = str.begin();
cit != str.end(); ++cit) {
if (*cit == '\n') {
Index: buffer.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/buffer.h,v
retrieving revision 1.188
diff -u -p -r1.188 buffer.h
--- buffer.h 24 Nov 2004 21:53:37 - 1.188
+++ buffer.h 17 Dec 2004 14:55:09 -
@@ -99,7 +99,7 @@ public:
///
void insertStringAsLines(ParagraphList & plist,
lyx::pit_type &, lyx::pos_type &,
- LyXFont const &, std::string const &);
+ LyXFont const &, std::string const &, bool);
///
ParIterator getParFromID(int id) const;
/// do we have a paragraph with this id?
Index: lyxtext.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxtext.h,v
retrieving revision 1.315
diff -u -p -r1.315 lyxtext.h
--- lyxtext.h 30 Nov 2004 01:59:34 - 1.315
+++ lyxtext.h 17 Dec 2004 14:55:09 -
@@ -352,6 +352,8 @@ public:
/// our 'outermost' Font
LyXFont font_;
+ ///
+ bool autoBreakRows_;
private:
/// return past-the-last paragraph influenced by a layout
/// change on pit
Index: paragraph.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/paragraph.C,v
retrieving revision 1.394
diff -u -p -r1.394 paragraph.C
--- paragraph.C 30 Nov 2004 01:59:34 - 1.394
+++ paragraph.C 17 Dec 2004 14:55:10 -
@@ -716,12 +716,6 @@ bool Paragraph::forceDefaultParagraphs()
}
-bool Paragraph::autoBreakRows() const
-{
- return inInset() && static_cast(inInset())->getAutoBreakRows();
-}
-
-
namespace {
// paragraphs inside floats need different alignment tags to avoid
Index: paragraph.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/paragraph.h,v
retrieving revision 1.144
diff -u -p -r1.144 paragraph.h
--- paragraph.h 30 Nov 2004 01:59:35 - 1.144
+++ paragraph.h 17 Dec 2004 14:55:10 -
@@ -169,8 +169,6 @@ public:
///
InsetBase::Code ownerCode() const;
///
- bool autoBreakRows() const;
- ///
bool forceDefaultParagraphs() const;
///
Index: text2.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text2.C,v
retrieving revision 1.590
diff -u -p -r1.590 text2.C
--- text2.C 6 Dec 2004 12:55:03 - 1.590
+++ text2.C 17 Dec 2004 14:55:10 -
@@ -74,7 +74,8 @@ using std::string;
LyXText::LyXText(BufferView * bv)
: maxwidth_(bv ? bv->workWidth() : 100),
background_color_(LColor::background),
- bv_owner(bv)
+ bv_owner(bv),
+ autoBreakRows_(false)
{}
@@ -893,7 +894,8 @@ void LyXText::insertStringAsLines(LCurso
// only to be sure, should not be neccessary
cur.clearSelection();
- cur.buffer().insertStringAsLines(pars_, pit, pos, current_font, str);
+ cur.buffer().insertStringAsLines(pars_, pit, pos, current_font, str,
+ autoBreakRows_);
cur.resetAnchor();
setCursor(cur, cur.pit(), pos);
Index: insets/insettext.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insettext.C,v
retrieving revision 1.602
diff -u -p -r1.602 insettext.C
--- insets/insettext.C 30 Nov 2004 01:59:47 - 1.602
+++ insets/insettext.C 17 Dec 2004 14:55:11 -
@@ -72,8 +72,7 @@ using std::vector;
InsetText::InsetText(BufferParams const & bp)
- : autoBreakRows_(false), drawFrame_(false),
- frame_color_(LColor::insetframe), text_(0)
+ : drawFrame_(false), frame_color_(LColor::insetframe), text_(0)
{
paragraphs().push_back(Paragraph());
paragraphs().back().layout(bp.getLyXTe
Re: Questions about path conversions
> Different idea: (almost) drop support for cygwin! > > Here is an idea I had while reading your message: we could also decide > that the cygwin version of LyX is a posix-like one, and that it can > only deal with unix-paths. This means that most special cygwin code > will go away, and that LyX/Cygwin will be basically LyX/Unix. > > People who want to interact with native windows apps will then use the > mingw (or msvc) version, which will always use windows paths. > > Does it look like an idea? I think it makes matters clearer. I think it makes sense. Kuba
Re: [PATCH 13x, 14x] mangling temporary file names
On piÄtek 17 grudzieÅ 2004 02:42 am, Georg Baum wrote: > Kuba Ober wrote: > > I vaguely recall this idea being raised at one point or another, but > > can't the temporary file names be simply generated from some kind of a > > unique global counter, maybe merged with PID? > > We have a global counter, it is prepended to the mangled name. Otherwise it > would not be unique. The reason for the additional mangling is that people > get a clue where a file comes from when something goes wrong. OK, makes sense. Thanks! Kuba
Re: Configure problems for lyx-140 on Mac
Kornel Benko <[EMAIL PROTECTED]> writes: > > > Try running > > > > > > $ ./autogen.sh > > > $ ./configure > > > > Doesn't make a difference (well, it does, before the make failed > > with: [other problem] > I had the same problem ... removing all autoconf caches cured it > > ./lib/reLyX/autom4te.cache > ./autom4te.cache autogen.sh already cured that already. It doesn't help with Bennet's probelm: unusable istream/ostream/etc. libraries It looks as if either the new boost version or this "concept checking" breaks on Mac. Any help there? /Andreas
Re: [PATCH 13x, 14x] determining the name of the LyX system dir
Jean-Marc Lasgouttes wrote: > Angus> Jean-Mac, aka MacJean. The Scottish JMarc. > > How did you find out? After all these years, everybody knows that I am > two. > > You can see him here: > http://www-rocq.inria.fr/~lasgoutt/emile/mac-cookies/emile-falaise.jpg ;-) -- Angus
Re: The remainder of Ruurd's changes
Jean-Marc Lasgouttes wrote: > Angus> You're just too clever for me ;-) However, static member > Angus> functions can't inherit > > Why is that? That's just the way the language works. > Angus> If you want to do something like that, then some sort of > Angus> indirection with "class os" hiding a member variable, is > Angus> inevitable I fear. > > Angus> Anyway, the principle point remains. Do you want to do this in > Angus> the 1.3.x series or should we leave that as "ugly but working"? > > OK, forget about that for the moment. It was just an idea that is not > needed now. What I do intend to do is follow up your idea of creating os_cygwin.C. First, however, let's get the functionality into the existing os_win32.C. It'll help us see what the differences between cygwin and windows are. -- Angus
Re: Questions about path conversions
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: >> A grep shows a lot of uses of slashify_path, I wonder what would >> happen if we changed these to internal_path. As far as I can see, >> this could do harm only on cygwin... Angus> Agree. Shall I prepare a patch? For 13x too? I think we should. It is not good to have two functions that do the same thing... Angus> I pulled the cygwin sources. Attached is the code for Angus> cygwin_conv_posix_path_to_win32 et al. Not exactly lightweight, Angus> is it? Yuck. Angus> Two questions arise. 1. Is it acceptable to always use Angus> internal_path, therefore, for cygwin or will there be a Angus> performance hit? I'd guess that it's Ok, but... I do not think there will be a performance hit, since each path should through it only once. However, read below for a different idea. Angus> 2. Why don't we need to do something similar for Windows? Is it Angus> because we plan to store the paths internally as C:/Windows/Bar Angus> and so don't have to worry about this mount table nonsense? It is because we do not know how to do it and we are forced to handle this colon :( **- Different idea: (almost) drop support for cygwin! Here is an idea I had while reading your message: we could also decide that the cygwin version of LyX is a posix-like one, and that it can only deal with unix-paths. This means that most special cygwin code will go away, and that LyX/Cygwin will be basically LyX/Unix. People who want to interact with native windows apps will then use the mingw (or msvc) version, which will always use windows paths. Does it look like an idea? I think it makes matters clearer. JMarc
Re: [PATCH 13x, 14x] mangling temporary file names
Jean-Marc Lasgouttes wrote: > OK, to answer to myself: I only read the 1.3.x version, not the > 1.4.0cvs one. I think your patches are OK, except that you should not > condition on cygwin or win32, but win32 or OS/2 (although I might be > wrong...). If we use 'internal_path' to convert any and all paths, then I think that you're right. I'll do some experimentation with the cygwin path.cc and ascertain just what cygwin_conv_win32_path_to_posix does, but I anticiapte that it converts c:\windows and c:/windows to /c/windows. -- Angus
Re: [PATCH 13x, 14x] determining the name of the LyX system dir
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: >> JMac Angus> Jean-Mac, aka MacJean. The Scottish JMarc. How did you find out? After all these years, everybody knows that I am two. You can see him here: http://www-rocq.inria.fr/~lasgoutt/emile/mac-cookies/emile-falaise.jpg Angus> I'll hold off on committing this until I have resolved the 'lyx Angus> -dbg init' problems. Sometime over the w/e. Angus> I'll commit the name-manglng patch now. Fine. JMarc
Re: Questions about path conversions
Jean-Marc Lasgouttes wrote: > Angus> Clearly, the fix is to ensure that the '\' characters are > Angus> converted '/' ones. However, what function am I supposed to > Angus> use? I find these: > > Angus> string os::slashify_path(string p) > > Angus> string os::internal_path(string const &p) > > Angus> So, on _WIN32 the two functions are identical. But what is > Angus> happening under cygwin? Anyone have any clue? > > I think we should probably use only internal_path and only work inside > LyX with paths which use / as separator. Of course, a second problem > is that win32 names will retain drive numbers, but stuff in filetools > should take care of that. > > A grep shows a lot of uses of slashify_path, I wonder what would > happen if we changed these to internal_path. As far as I can see, this > could do harm only on cygwin... Agree. Shall I prepare a patch? For 13x too? > I would say that all paths that come from the os should go through > internal_path and then external_path should be used for all processes > invocations. I pulled the cygwin sources. Attached is the code for cygwin_conv_posix_path_to_win32 et al. Not exactly lightweight, is it? Two questions arise. 1. Is it acceptable to always use internal_path, therefore, for cygwin or will there be a performance hit? I'd guess that it's Ok, but... 2. Why don't we need to do something similar for Windows? Is it because we plan to store the paths internally as C:/Windows/Bar and so don't have to worry about this mount table nonsense? -- Angus path.cc.bz2 Description: BZip2 compressed data
Re: [patch] encoding error
On Fri, 2004-12-17 at 14:46, Juergen Spitzmueller wrote:
> Georg Baum wrote:
> > IMHO a clean solution
> > would be to support one of the units packages (e.g. SIunits) and remove Ã
> > and Ã. But this is probably post 1.4 stuff.
>
> Agreed.
>
> > > Actually the attached works on-screen, but I don't feel good about
> > > latin-1 characters embedded in text files. Better ideas?
> >
> > This solution is better than latin1 characters in ControlMath.C, because
> > only the onscreen display may be wrong for non-latin1 documents, and one
> > can change it without recompiling. I would suggest to do it this way (with
> > a FIXME comment in lib/symbols), until Andrà has some time to look at it.
>
> Agreed too.
>
> JÃrgen.
Ok, here is the complete patch then. To go in presently, under general
cheering.
- Martin
Index: src/frontends/controllers/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/ChangeLog,v
retrieving revision 1.461
diff -u -r1.461 ChangeLog
--- src/frontends/controllers/ChangeLog 3 Dec 2004 13:57:47 - 1.461
+++ src/frontends/controllers/ChangeLog 17 Dec 2004 13:17:56 -
@@ -1,3 +1,7 @@
+2004-12-17 Martin Vermeer <[EMAIL PROTECTED]>
+
+ * ControlMath.C: fixed Ångström, Ørsted.
+
2004-12-02 Georg Baum <[EMAIL PROTECTED]>
* ControlTabular.[Ch], ControlTabularCreate.h: use size_t-like
Index: src/frontends/controllers/ControlMath.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/ControlMath.C,v
retrieving revision 1.26
diff -u -r1.26 ControlMath.C
--- src/frontends/controllers/ControlMath.C 19 May 2004 15:11:30 - 1.26
+++ src/frontends/controllers/ControlMath.C 17 Dec 2004 13:18:44 -
@@ -177,7 +177,7 @@
"angle", "top", "bot", "Vert", "neg",
"flat", "natural", "sharp", "surd", "triangle",
"diamondsuit", "heartsuit", "clubsuit", "spadesuit",
- "textrm Ã", "textrm Ã", "mathcircumflex", "_",
+ "textrm \\AA", "textrm \\O", "mathcircumflex", "_",
"mathrm T",
"mathbb N", "mathbb Z", "mathbb Q",
"mathbb R", "mathbb C", "mathbb H",
@@ -333,8 +333,8 @@
{ "nRightarrow", "nrightarrow2" },
{ "nVDash", "nvdash3" },
{ "nvDash", "nvdash2" },
- { "textrm_Ã", "textrm_A" },
- { "textrm_Ã", "textrm_0" },
+ { "textrm \\AA", "textrm_AA"},
+ { "textrm \\O", "textrm_Oe"},
{ "vDash", "vdash2" }
};
Index: lib/images/math/textrm_AA.xpm
===
RCS file: lib/images/math/textrm_AA.xpm
diff -N lib/images/math/textrm_AA.xpm
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lib/images/math/textrm_AA.xpm 17 Dec 2004 13:19:31 -
@@ -0,0 +1,27 @@
+/* XPM */
+static char *a[] = {
+/* columns rows colors chars-per-pixel */
+"12 19 2 1",
+" c #00",
+". c None",
+/* pixels */
+" .",
+"... ... ",
+"... ... ",
+"... ... ",
+"... ... ",
+" .",
+". .",
+" .",
+" . ",
+"... .. ",
+"... ... ...",
+"... ... ...",
+".. ...",
+".. . ..",
+"....",
+".. . ..",
+". ... .",
+". ... .",
+" ."
+};
Index: lib/images/math/textrm_Oe.xpm
===
RCS file: lib/images/math/textrm_Oe.xpm
diff -N lib/images/math/textrm_Oe.xpm
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lib/images/math/textrm_Oe.xpm 17 Dec 2004 13:19:31 -
@@ -0,0 +1,24 @@
+/* XPM */
+static char *a[] = {
+/* columns rows colors chars-per-pixel */
+"13 16 2 1",
+" c #00",
+". c None",
+/* pixels */
+".. ",
+" .. . .",
+"... . ..",
+".. . . .",
+". .. . .",
+". . ... ",
+" . ",
+" . ",
+" . ",
+" ... .. ",
+". ... .. ",
+". . ... ",
+".. ... ",
+".. .. .",
+".. . ..",
+". ... ..."
+};
Index: lib/symbols
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/symbols,v
retrieving revision 1.46
diff -u -r1.46 symbols
--- lib/symbols 18 Apr 2004 07:33:32 - 1.46
+++ lib/symbols 17 Dec 2004 13:19:31 -
@@ -811,6 +811,9 @@
\def\Join{\ltimes\kern-18.5mu\rtimes}
endif
\def\mathcircumflex{\mbox{\^{}}}{\^}
+# Fixme: latin-1 chars in text file
+\def\AA{\AA}{Å}
+\def\O{\O}{Ø}
textdegree lyxsymbol 176 0 mathord x
Index: lib/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/ChangeLog,v
retrieving revision 1.656
diff -u -r1.656 ChangeLog
--- lib/ChangeLog 16 Dec 2004 14:46:49 - 1.656
+++ lib/ChangeLog 17 Dec 2004 13:19:33 -
@@ -1,3 +1,8 @@
+2004-12-17 Martin Vermer <[EMAIL PROTECTED]>
+
+ * images/math/textrm_*.xpm: renamed to textrm_AA, textrm_Oe
+ * symbols: added Ångström, Ørsted
+
2004-12-16 Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
* configure.m4: remove
Re: Should GetEnvPath be changed?
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Do you agree? Else Win32 drive names will become path Angus> separators. I think your change is OK. Angus> I take it that the PATH environment variable under cygwin Angus> returns fully Posix-ified paths? (/c/windows/system32 ?) I do not know, but this seems reasonable. JMarc
Re: [PATCH 13x, 14x] mangling temporary file names
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Given a file name "C:/foo/bar", I believe that the name of the Angus> temporary file should be "C__foo_bar". Ie, the drive name Angus> should be included in the mangling. Ruurd was addressing this Angus> idea in his patch, but he simply removed the drive prefix from Angus> the mangled name. Angus> Do you agree that my approach is better? If so, are you happy Angus> with the attached patches for the 13x and 14x trees? Jean-Marc> What about a new os::mangle_path? This will be needed for Jean-Marc> os/2 too, but not for cygwin AFAIK (if we know that the Jean-Marc> path went through internal_path). OK, to answer to myself: I only read the 1.3.x version, not the 1.4.0cvs one. I think your patches are OK, except that you should not condition on cygwin or win32, but win32 or OS/2 (although I might be wrong...). JMarc
Re: [patch] encoding error
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes: Juergen> Georg Baum wrote: >> IMHO a clean solution would be to support one of the units packages >> (e.g. SIunits) and remove Å and Ø. But this is probably post 1.4 >> stuff. Juergen> Agreed. [...] Juergen> Agreed too. Me too! JMarc
Re: The remainder of Ruurd's changes
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> You're just too clever for me ;-) However, static member Angus> functions can't inherit Why is that? Angus> If you want to do something like that, then some sort of Angus> indirection with "class os" hiding a member variable, is Angus> inevitable I fear. Angus> Anyway, the principle point remains. Do you want to do this in Angus> the 1.3.x series or should we leave that as "ugly but working"? OK, forget about that for the moment. It was just an idea that is not needed now. JMarc
Re: [PATCH 13x, 14x] mangling temporary file names
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Given a file name "C:/foo/bar", I believe that the name of the Angus> temporary file should be "C__foo_bar". Ie, the drive name Angus> should be included in the mangling. Ruurd was addressing this Angus> idea in his patch, but he simply removed the drive prefix from Angus> the mangled name. Angus> Do you agree that my approach is better? If so, are you happy Angus> with the attached patches for the 13x and 14x trees? What about a new os::mangle_path? This will be needed for os/2 too, but not for cygwin AFAIK (if we know that the path went through internal_path). I think we should avoid #ifdef in any places that are not near the system (like insetgraphics). Angus> Jean-Marc, I'll hang back and await your feedback on this; I've Angus> been a bit rushy with my application of some of the other Angus> patches. Sorry 'bout that. No problem, I do not think that any harm has been done. JMarc
Re: Questions about path conversions
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Clearly, the fix is to ensure that the '\' characters are Angus> converted '/' ones. However, what function am I supposed to Angus> use? I find these: Angus> string os::slashify_path(string p) Angus> string os::internal_path(string const &p) Angus> So, on _WIN32 the two functions are identical. But what is Angus> happening under cygwin? Anyone have any clue? I think we should probably use only internal_path and only work inside LyX with paths which use / as separator. Of course, a second problem is that win32 names will retain drive numbers, but stuff in filetools should take care of that. A grep shows a lot of uses of slashify_path, I wonder what would happen if we changed these to internal_path. As far as I can see, this could do harm only on cygwin... I would say that all paths that come from the os should go through internal_path and then external_path should be used for all processes invocations. JMarc
Should GetEnvPath be changed?
Do you agree? Else Win32 drive names will become path separators.
string const GetEnvPath(string const & name)
{
-#ifndef __EMX__
- string const pathlist = subst(GetEnv(name), ':', ';');
-#else
- string const pathlist = os::slashify_path(GetEnv(name));
-#endif
+ string pathlist = GetEnv(name);
+#if !defined (__EMX__) && !defined(_WIN32)
+ pathlist = subst(pathlist, ':', ';');
+#endif
+ pathlist = os::slashify_path(GetEnv(name));
return rtrim(pathlist, ";");
}
I take it that the PATH environment variable under cygwin returns fully
Posix-ified paths? (/c/windows/system32 ?)
--
Angus
Re: [patch] encoding error
Georg Baum wrote: > IMHO a clean solution > would be to support one of the units packages (e.g. SIunits) and remove Å > and Ø. But this is probably post 1.4 stuff. Agreed. > > Actually the attached works on-screen, but I don't feel good about > > latin-1 characters embedded in text files. Better ideas? > > This solution is better than latin1 characters in ControlMath.C, because > only the onscreen display may be wrong for non-latin1 documents, and one > can change it without recompiling. I would suggest to do it this way (with > a FIXME comment in lib/symbols), until André has some time to look at it. Agreed too. Jürgen.
Re: [patch] encoding error
Martin Vermeer wrote:
> On Fri, 2004-12-17 at 13:02, Martin Vermeer wrote:
>> On Tue, 2004-12-14 at 08:42, Martin Vermeer wrote:
>> > These are meant to be the units Ångström and Ørsted. So you need a
>> > Swedish Å (\AA is OK I think) and a Danish Ø (\O).
The \textrm in front of them is a hack. You get \textrm{Å\textrm{Ø}} if you
insert one directly after the other, which is wrong. IMHO a clean solution
would be to support one of the units packages (e.g. SIunits) and remove Å
and Ø. But this is probably post 1.4 stuff.
> Actually the attached works on-screen, but I don't feel good about
> latin-1 characters embedded in text files. Better ideas?
This solution is better than latin1 characters in ControlMath.C, because
only the onscreen display may be wrong for non-latin1 documents, and one
can change it without recompiling. I would suggest to do it this way (with
a FIXME comment in lib/symbols), until André has some time to look at it.
Georg
Re: [PATCH 13x, 14x] determining the name of the LyX system dir
Jean-Marc Lasgouttes wrote: > Angus> Ok, Jean-Marc. Here is a refinement of Ruurd's patch to > Angus> determine the name of the LyX system directory from the name of > Angus> the LyX binary. Are you happy with this or should we discuss it > Angus> some more? > > I am very happy with this :) > > JMac Jean-Mac, aka MacJean. The Scottish JMarc. I'll hold off on committing this until I have resolved the 'lyx -dbg init' problems. Sometime over the w/e. I'll commit the name-manglng patch now. -- Angus
Re: [PATCH 13x, 14x] determining the name of the LyX system dir
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Ok, Jean-Marc. Here is a refinement of Ruurd's patch to Angus> determine the name of the LyX system directory from the name of Angus> the LyX binary. Are you happy with this or should we discuss it Angus> some more? I am very happy with this :) JMac
Re: Configure problems for lyx-140 on Mac
On Freitag 17 Dezember 2004 04:47, Andreas Vox wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > > > > > Bennett Helm wrote: > > > > > Trying to build the latest CVS of lyx-140 in Mac OS X forced rerunning > > > configure, which fails. I get variants of the following error with each > > > of ostream, istream, sstream, locale, ios, and Aiksaurus: > > Same with me. > > > > > Try running > > > > $ ./autogen.sh > > $ ./configure > > Doesn't make a difference (well, it does, before the make failed > with: I had the same problem ... removing all autoconf caches cured it ./lib/reLyX/autom4te.cache ./autom4te.cache Kornel -- Kornel Benko [EMAIL PROTECTED]
Re: [patch] encoding error
On Fri, 2004-12-17 at 13:02, Martin Vermeer wrote:
> On Tue, 2004-12-14 at 08:42, Martin Vermeer wrote:
> > On Mon, 2004-12-13 at 20:55, Juergen Spitzmueller wrote:
> > > Jean-Marc Lasgouttes wrote:
> > >
> > > > Juergen> - "textrm ÃÂ", "textrm ÃÂ", "mathcircumflex", "_",
> > > > Juergen> + "textrm Ã", "textrm Ã", "mathcircumflex", "_",
> > > >
> > > > Is it really a good idea to have stuff in latin1 included
> > > > unconditionally? Why not use "AA" and "emptyset"?
> > >
> > > Yes, I agree, but I think that \textrm{Ã} is rather synonymical to
> > > \textrm{\O} than to \textrm{\emptyset} (which also triggers a LaTeX
> > > error).
> > > But OTOH I am no mathematician.
> > >
> > > Also, mathed does not render \AA and \O to symbols ATM, but I guess AndrÃ
> > > could fix that easily.
> > >
> > > JÃrgen.
> >
> > I suppose I am guilty here.
> >
> > These are meant to be the units ÃngstrÃm and Ãrsted. So you need a
> > Swedish à (\AA is OK I think) and a Danish à (\O).
>
> Attached a patch which outputs the right LaTeX AND shows correctly in
> the panel. Note that I renamed the two XPM files to be more self
> documenting (and the second one had nothing to do with the number zero
> or the empty set anyway).
>
> Andrà should look at lib/symbols, I'm lost there too :-)
Actually the attached works on-screen, but I don't feel good about
latin-1 characters embedded in text files. Better ideas?
> - Martin
Index: symbols
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/symbols,v
retrieving revision 1.46
diff -u -r1.46 symbols
--- symbols 18 Apr 2004 07:33:32 - 1.46
+++ symbols 17 Dec 2004 11:25:20 -
@@ -811,6 +811,8 @@
\def\Join{\ltimes\kern-18.5mu\rtimes}
endif
\def\mathcircumflex{\mbox{\^{}}}{\^}
+\def\AA{\AA}{Å}
+\def\O{\O}{Ø}
textdegree lyxsymbol 176 0 mathord x
signature.asc
Description: This is a digitally signed message part
Re: [patch] encoding error
On Tue, 2004-12-14 at 08:42, Martin Vermeer wrote:
> On Mon, 2004-12-13 at 20:55, Juergen Spitzmueller wrote:
> > Jean-Marc Lasgouttes wrote:
> >
> > > Juergen> - "textrm ÃÂ", "textrm ÃÂ", "mathcircumflex", "_",
> > > Juergen> + "textrm Ã", "textrm Ã", "mathcircumflex", "_",
> > >
> > > Is it really a good idea to have stuff in latin1 included
> > > unconditionally? Why not use "AA" and "emptyset"?
> >
> > Yes, I agree, but I think that \textrm{Ã} is rather synonymical to
> > \textrm{\O} than to \textrm{\emptyset} (which also triggers a LaTeX error).
> > But OTOH I am no mathematician.
> >
> > Also, mathed does not render \AA and \O to symbols ATM, but I guess AndrÃ
> > could fix that easily.
> >
> > JÃrgen.
>
> I suppose I am guilty here.
>
> These are meant to be the units ÃngstrÃm and Ãrsted. So you need a
> Swedish à (\AA is OK I think) and a Danish à (\O).
Attached a patch which outputs the right LaTeX AND shows correctly in
the panel. Note that I renamed the two XPM files to be more self
documenting (and the second one had nothing to do with the number zero
or the empty set anyway).
Andrà should look at lib/symbols, I'm lost there too :-)
- Martin
Index: src/frontends/controllers/ControlMath.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/ControlMath.C,v
retrieving revision 1.26
diff -u -r1.26 ControlMath.C
--- src/frontends/controllers/ControlMath.C 19 May 2004 15:11:30 - 1.26
+++ src/frontends/controllers/ControlMath.C 17 Dec 2004 10:37:35 -
@@ -177,7 +177,7 @@
"angle", "top", "bot", "Vert", "neg",
"flat", "natural", "sharp", "surd", "triangle",
"diamondsuit", "heartsuit", "clubsuit", "spadesuit",
- "textrm Ã", "textrm Ã", "mathcircumflex", "_",
+ "textrm \\AA", "textrm \\O", "mathcircumflex", "_",
"mathrm T",
"mathbb N", "mathbb Z", "mathbb Q",
"mathbb R", "mathbb C", "mathbb H",
@@ -333,8 +333,8 @@
{ "nRightarrow", "nrightarrow2" },
{ "nVDash", "nvdash3" },
{ "nvDash", "nvdash2" },
- { "textrm_Ã", "textrm_A" },
- { "textrm_Ã", "textrm_0" },
+ { "textrm \\AA", "textrm_AA"},
+ { "textrm \\O", "textrm_Oe"},
{ "vDash", "vdash2" }
};
Index: lib/images/math/textrm_AA.xpm
===
RCS file: lib/images/math/textrm_AA.xpm
diff -N lib/images/math/textrm_AA.xpm
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lib/images/math/textrm_AA.xpm 17 Dec 2004 10:38:39 -
@@ -0,0 +1,27 @@
+/* XPM */
+static char *a[] = {
+/* columns rows colors chars-per-pixel */
+"12 19 2 1",
+" c #00",
+". c None",
+/* pixels */
+" .",
+"... ... ",
+"... ... ",
+"... ... ",
+"... ... ",
+" .",
+". .",
+" .",
+" . ",
+"... .. ",
+"... ... ...",
+"... ... ...",
+".. ...",
+".. . ..",
+"....",
+".. . ..",
+". ... .",
+". ... .",
+" ."
+};
Index: lib/images/math/textrm_Oe.xpm
===
RCS file: lib/images/math/textrm_Oe.xpm
diff -N lib/images/math/textrm_Oe.xpm
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lib/images/math/textrm_Oe.xpm 17 Dec 2004 10:38:39 -
@@ -0,0 +1,24 @@
+/* XPM */
+static char *a[] = {
+/* columns rows colors chars-per-pixel */
+"13 16 2 1",
+" c #00",
+". c None",
+/* pixels */
+".. ",
+" .. . .",
+"... . ..",
+".. . . .",
+". .. . .",
+". . ... ",
+" . ",
+" . ",
+" . ",
+" ... .. ",
+". ... .. ",
+". . ... ",
+".. ... ",
+".. .. .",
+".. . ..",
+". ... ..."
+};
signature.asc
Description: This is a digitally signed message part
Re: license for documentation?
On Tue, 14 Dec 2004, Jeremy C. Reed wrote: > Does the COPYING file apply to all the doc/ documentation that don't have > any license in them? > > For example, I don't see any republishing or reuse license for > lib/doc/Customization.lyx. It is a good question. When the documentation was written, the concept of licenses for documentation was not really crystalised yet. So, the question was never really asked and thus never answered. I believe that a fair interpretation of intent is that the documentation is GPL. > I want to test a print-on-demand service. I want to submit the LyX > documentation in a single PDF format for a single book. Is this okay? I belive that would be ok, but you might try to ask John Weiss who is the main author of the documentation, and as such he would be the main copyright holder, although many, many people have contributed, including Matthias Ettrich who wrote the initial documentation on which everything is based. I believe he would be the person that defined the original license, although it was implicit. See Credits for more info on contributors. My personal oppinion is that a printed version of LyX documentation would be a very welcome contribution to the community. A book with a CD in it would definately be nice, especially if some of the profits were donated to the LyX meeting sponsoring fund. Regards, Asger Ottar Alstrup
Re: MSVC wrapper
On Wed, 15 Dec 2004, Angus Leeming wrote: > I see that the wrapmsvc.cpp depends on cygwin32_conv_to_win32_path and > cygwin32_conv_to_posix_path. I'm sure that it's possible to replace those. > I'll > have a go when I come to try out MSVC. If it takes 24 minutes to link with Ming, then you should have plenty of time to do the MSVC porting in the meantime :-) Regards, Asger
Questions about path conversions
Trying to get to the bottom of this:
$ ~/lyx-13x/build-qt/src/lyx.exe -dbg init
Name of binary: J:\MinSYS\home\Angus\lyx-13x\build-qt\src\lyx.exe
Path of binary: J:/MinSYS/home/Angus/qt3/bin/
I find that binname is currently initialised as:
void os::init(int /* argc */, char * argv[])
{
static bool initialized = false;
if (initialized) return;
initialized = true;
string tmp = argv[0];
binname_ = OnlyFilename(tmp);
Clearly, the fix is to ensure that the '\' characters are converted '/'
ones. However, what function am I supposed to use? I find these:
string os::slashify_path(string p)
{
return subst(p, '\\', '/');
}
string os::internal_path(string const &p)
{
#ifdef __CYGWIN__
char pp[MAX_PATH];
cygwin_conv_to_posix_path(p.c_str(), pp);
string const posix_path = MakeLatexName(pp);
#else
string const posix_path = subst(p,"\\","/");
#endif
return posix_path;
}
So, on _WIN32 the two functions are identical. But what is happening under
cygwin? Anyone have any clue?
--
Angus
Re: [PATCH 13x, 14x] determining the name of the LyX system dir
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>
>> Angus Leeming <[EMAIL PROTECTED]> writes:
>>
>> | @@ -217,8 +217,19 @@ bool setLyxPaths()
>> | bool followlink;
>> | do {
>> | // Path of binary/../share/name of binary/
>> | - searchpath += NormalizePath(AddPath(binpath, "../share/") +
>> | - OnlyFilename(binname)) + ';';
>> | +
>> | + string const exe_name = OnlyFilename(binname);
>> | + string const lyx_system_dir_name =
>> | +#ifdef _WIN32
>> | + suffixIs(exe_name, ".exe") ?
>> | + ChangeExtension(exe_name, "") :
>> | + exe_name;
>> | +#else
>> | + exe_name;
>> | +#endif
>>
>> Can we please not split statements with ifdef?
>
| Sure, but that is just more 'whitespace commentary'. Are you in favour of
| the substance of the proposal or should we take this back to the drawing
| board?
I comment what I comment. I.e. if I don't comment the general approach
I am fine with it.
--
Lgb
