Re: "Branch: titlepage" gets read as color?
On Thu, Mar 25, 2004 at 05:26:40PM +0100, Jean-Marc Lasgouttes spake thusly: > Martin> It's in -- under both our names (is that legal?) > > Thanks. What could be illegal about it? "That's not the way to write a change log." :-) - Martin pgp0.pgp Description: PGP signature
Re: "Branch: titlepage" gets read as color?
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: Martin> It's in -- under both our names (is that legal?) Thanks. What could be illegal about it? JMarc
Re: "Branch: titlepage" gets read as color?
On Wed, Mar 24, 2004 at 09:04:21PM +0200, Martin Vermeer spake thusly: > > Why did you drop the part in src/lyxfunc.C? > > Oops, yes. > > > Martin> The "\color default" issue is still there, even though it gets > > Martin> converted now to "none" instead of crashing on assert. Any > > Martin> thoughts on that? > > > > Not really (I am not sure I understand the difference between inherit > > and none). However, I think that it would not hurt to have lyx2lyx > > get us rid of these "default". > > I'll think a little more about that, but go ahead with the above patch > (with lyxfunc.C and ChangeLog included this time) if it is OK with you. It's in -- under both our names (is that legal?) - Martin pgp0.pgp Description: PGP signature
Re: "Branch: titlepage" gets read as color?
On Wed, Mar 24, 2004 at 01:03:48PM +0100, Jean-Marc Lasgouttes spake thusly: > > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: > > Martin> Yes, this works as well. Working and tested patch attached. > > Why did you drop the part in src/lyxfunc.C? Oops, yes. > Martin> The "\color default" issue is still there, even though it gets > Martin> converted now to "none" instead of crashing on assert. Any > Martin> thoughts on that? > > Not really (I am not sure I understand the difference between inherit > and none). However, I think that it would not hurt to have lyx2lyx > get us rid of these "default". I'll think a little more about that, but go ahead with the above patch (with lyxfunc.C and ChangeLog included this time) if it is OK with you. > JMarc - Martin pgp0.pgp Description: PGP signature
Re: "Branch: titlepage" gets read as color?
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Jean-Marc Lasgouttes wrote:
>> Not really (I am not sure I understand the difference between
>> inherit and none). However, I think that it would not hurt to have
>> lyx2lyx get us rid of these "default".
Angus> Jean-Marc,
Angus> I tried to run the preview code last night and found that the
Angus> latex file contained the line.
Angus> \unknown{}\unknown{}\unknown{}\unknown{}
Angus> somewhere in the lyx-generated preamble. Removing this line
Angus> (bit of sed magic in lyxpreview2bitmap.sh) enabled the
Angus> compilation to succeed.
Angus> This smacks of this colour stuff, no?
Yes, maybe (but I did not find code that would produce this). Could
you send a specific example?
JMarc
Re: "Branch: titlepage" gets read as color?
Jean-Marc Lasgouttes wrote:
> Not really (I am not sure I understand the difference between
> inherit and none). However, I think that it would not hurt to have
> lyx2lyx get us rid of these "default".
Jean-Marc,
I tried to run the preview code last night and found that the latex
file contained the line.
\unknown{}\unknown{}\unknown{}\unknown{}
somewhere in the lyx-generated preamble. Removing this line (bit of
sed magic in lyxpreview2bitmap.sh) enabled the compilation to succeed.
This smacks of this colour stuff, no?
André,
Having hacked lyxpreview2bitmap.sh to get the compilation to succeed,
I find that previewing of Include insets works fine but that no
previews are displayed for math insets.
Any ideas?
--
Angus
Re: "Branch: titlepage" gets read as color?
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: Martin> Yes, this works as well. Working and tested patch attached. Why did you drop the part in src/lyxfunc.C? Martin> The "\color default" issue is still there, even though it gets Martin> converted now to "none" instead of crashing on assert. Any Martin> thoughts on that? Not really (I am not sure I understand the difference between inherit and none). However, I think that it would not hurt to have lyx2lyx get us rid of these "default". JMarc
Re: "Branch: titlepage" gets read as color?
On Tue, Mar 23, 2004 at 06:42:15PM +0100, Alfredo Braunstein wrote: > Angus Leeming wrote: > > > The maximum positive integer that can fit into an int is 0x7fff or > > 2^(32)-1. > > And I suppose that when you say 32 you mean 31 :-) No, he means 'implementation defined' ;-) Andre'
Re: "Branch: titlepage" gets read as color?
On Tue, Mar 23, 2004 at 04:47:50PM +, Angus Leeming wrote: > The maximum positive integer that can fit into an int is 0x7fff or > 2^(32)-1. This hypothesis is not covered by The Holy Standard. Andre'
Re: "Branch: titlepage" gets read as color?
On Tue, Mar 23, 2004 at 02:02:18PM +0100, Lars Gullik Bjønnes wrote: > | Angus> Looking at debug.h, I think we've run out of space in the > | Angus> lyx_debug_trai::type enum. 2^24 > 0xff (by 1 ;-) > > we should be able to go to 2^32. (or at least 31) But then we'd drop support for this bunch of 24 bit signal processors out there... Andre'
Re: "Branch: titlepage" gets read as color?
On Mon, Mar 22, 2004 at 09:12:56AM +, Angus Leeming wrote: > > Should this be made more clearly a warning or info message? Like > > "... Color \"" << lyxname << '"' added to color table" << endl ? > > Yes. That is exactly what the code is doing, after all. Moreover, I > think that the warning should be output in debug mode only. > > lyxerr[your debug flavour] << ...; Good idea... Andre'
Re: "Branch: titlepage" gets read as color?
Alfredo Braunstein wrote:
> Angus Leeming wrote:
>
>> The maximum positive integer that can fit into an int is 0x7fff
>> or 2^(32)-1.
>
> And I suppose that when you say 32 you mean 31 :-)
> Alfredo
Looks like ;-)
#include
#include
int main()
{
int const ANY = (1 << 31) - 1;
std::cout << "ANY == (1 << 31) - 1\n";
std::cout << "ANY == " << ANY << ", ";
std::cout.setf(std::ios::showbase);
std::cout.setf(std::ios::hex, std::ios::basefield);
std::cout << ANY << '\n';
std::cout.setf(std::ios::fixed, std::ios::basefield);
std::cout << "ANY + 1 == " << ANY + 1 << ", ";
std::cout.setf(std::ios::showbase);
std::cout.setf(std::ios::hex, std::ios::basefield);
std::cout << ANY + 1 << '\n';
return 0;
}
--
Angus
Re: "Branch: titlepage" gets read as color?
Lars Gullik Bjønnes wrote:
> What does the standard say about enums again?
Dunno.
The 1996 Draft Standard says this:
[dcl.enum] 7.2 Enumeration declarations
1 An enumeration is a distinct type (3.9.1) with named constants. Its
name becomes an enumname, within its scope.
enumname:
identifier
enumspecifier:
enum identifier_opt { enumerator-list_opt }
enumerator-list:
enumerator-definition
enumerator-list , enumerator-definition
enumerator-definition:
enumerator
enumerator = constant-expression
enumerator:
identifier
The identifiers in an enumerator-list are declared as constants, and
can appear wherever constants are required. If no
enumerator-definitions with = appear, then the values of the
corresponding constants begin at zero and increase by one as the
enumerator-list is read from left to right. An enumerator-definition
with = gives the associated enumerator the value indicated by the
constantexpression; subsequent enumerators without initializers
continue the progression from the assigned value. The
constant-expression shall be of integral or enumeration type.
2 [Example:
enum { a, b, c=0 };
enum { d, e, f=e+2 };
defines a, c, and d to be zero, b and e to be 1, and f to be 3. ]
3 The point of declaration for an enumerator is immediately after its
enumerator-definition. [Example:
const int x = 12;
{ enum { x = x }; }
Here, the enumerator x is initialized with the value of the constant
x, namely 12. ]
4 Each enumeration defines a type that is different from all other
types. The type of an enumerator is its enumeration.
5 The underlying type of an enumeration is an integral type that can
represent all the enumerator values defined in the enumeration. It is
implementationdefined which integral type is used as the underlying
type for an enumeration except that the underlying type shall not be
larger than int unless the value of an enumerator cannot fit in an
int or unsigned int. If the enumerator-list is empty, the underlying
type is as if the enumeration had a single enumerator with value 0.
The value of sizeof() applied to an enumeration type, an object of
enumeration type, or an enumerator, is the value of sizeof() applied
to the underlying type.
6 For an enumeration where emin is the smallest enumerator and emax is
the largest, the values of the enumeration are the values of the
underlying type in the range bmin to bmax, where bmin and bmax are,
respectively, the smallest and largest values of the smallest
bitfield that can store emin and emax. 77) It is possible to define
an enumeration that has values not defined by any of its enumerators.
7 Two enumeration types are layout-compatible if they have the same
underlying type.
8 The value of an enumerator or an object of an enumeration type is
converted to an integer by integral promotion (4.5). [Example:
enum color { red, yellow, green=20, blue };
color col = red;
color* cp = &col;
if (*cp == blue) // ...
makes color a type describing various colors, and then declares col as
an object of that type, and cp as a pointer to an object of that
type. The possible values of an object of type color are red, yellow,
green, blue; these values can be converted to the integral values 0,
1, 20, and 21. Since enumerations are distinct types, objects of type
color can be assigned only values of type color.
color c = 1; // error: type mismatch,
// no conversion from int to color
int i = yellow; // ok: yellow converted to integral value 1
// integral promotion
See also C.3. ]
9 An expression of arithmetic or enumeration type can be converted to
an enumeration type explicitly. The value is unchanged if it is in
the range of enumeration values of the enumeration type; otherwise
the resulting enumeration value is unspecified.
10 The enum-name and each enumerator declared by an enum-specifier is
declared in the scope that immediately contains the enum-specifier.
These names obey the scope rules defined for all names in (3.3) and
(3.4). An enumerator declared in class scope can be referred to using
the class member access operators (::, . (dot) and -> (arrow)), see
5.2.5. [Example:
class X {
public:
enum direction { left= l , right= r };
int f(int i)
{ return i==left ? 0 : i==right ? 1 : 2; }
};
void g(X* p)
{
direction d; // error: direction not in scope
int i;
i = p->f(left); // error: left not in scope
i = p->f(X::right); // ok
i = p->f(p->left); // ok
// ...
}
--end example]
77) On a twos-complement machine, bmax is the smallest value greater
than or equal to max (abs(emin ) - 1 ,abs(emax ) ) of the form 2M -
1; bmin is zero if emin is nonnegative and - (bmax + 1 ) otherwise.
--
Angus
Re: "Branch: titlepage" gets read as color?
Angus Leeming wrote: > The maximum positive integer that can fit into an int is 0x7fff or > 2^(32)-1. And I suppose that when you say 32 you mean 31 :-) Alfredo
Re: "Branch: titlepage" gets read as color?
On Tue, Mar 23, 2004 at 05:17:12PM +0100, Jean-Marc Lasgouttes spake thusly:
>
> > "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
> Martin> Yes, this sounds good. I did this, calling the creating
> Martin> function LColor::getFromLyXNameOrAdd(). Not a splendid choice,
> Martin> but...
>
> Jean-Marc> This is not exactly what I had in mind, but rather
> Jean-Marc> something like the patch below (which is completely
> Jean-Marc> untested). I think it is better since it is never possible
> Jean-Marc> to create a new color entry that is not associated to a
> Jean-Marc> x11name. And I think the semantics look good.
>
> Umph. Here is the patch.
>
> JMarc
Yes, this works as well. Working and tested patch attached.
The "\color default" issue is still there, even though it gets
converted now to "none" instead of crashing on assert. Any thoughts on
that?
-Martin
Index: LColor.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/LColor.C,v
retrieving revision 1.51
diff -u -p -r1.51 LColor.C
--- LColor.C18 Mar 2004 15:49:44 - 1.51
+++ LColor.C23 Mar 2004 17:12:49 -
@@ -229,6 +229,21 @@ bool LColor::setColor(LColor::color col,
}
+bool LColor::setColor(string const & lyxname, string const &x11name)
+{
+ string const lcname = ascii_lowercase(lyxname);
+ if (pimpl_->transform.find(lcname) == pimpl_->transform.end()) {
+ lyxerr[Debug::GUI]
+ << "LColor::setColor: Unknown color \""
+ << lyxname << '"' << endl;
+ addColor(static_cast(pimpl_->infotab.size()), lcname);
+ }
+
+ return setColor(static_cast(pimpl_->transform[lcname]),
+ x11name);
+}
+
+
LColor::color LColor::getFromGUIName(string const & guiname) const
{
Pimpl::InfoTab::const_iterator it = pimpl_->infotab.begin();
@@ -254,7 +269,7 @@ LColor::color LColor::getFromLyXName(str
if (pimpl_->transform.find(lcname) == pimpl_->transform.end()) {
lyxerr << "LColor::getFromLyXName: Unknown color \""
<< lyxname << '"' << endl;
- addColor(static_cast(pimpl_->infotab.size()), lcname);
+ return none;
}
return static_cast(pimpl_->transform[lcname]);
Index: LColor.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/LColor.h,v
retrieving revision 1.40
diff -u -p -r1.40 LColor.h
--- LColor.h14 Dec 2003 16:33:51 - 1.40
+++ LColor.h23 Mar 2004 17:12:49 -
@@ -198,6 +198,12 @@ public:
*/
bool setColor(LColor::color col, std::string const & x11name);
+ /** set the given LyX color to the color defined by the X11
+* name given \returns true if successful. A new color entry
+* is created if the color is unknown
+*/
+ bool setColor(std::string const & lyxname, std::string const & x11name);
+
/// Get the GUI name of \c color.
std::string const getGUIName(LColor::color c) const;
Index: bufferparams.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/bufferparams.C,v
retrieving revision 1.77
diff -u -p -r1.77 bufferparams.C
--- bufferparams.C 7 Mar 2004 14:33:17 - 1.77
+++ bufferparams.C 23 Mar 2004 17:12:49 -
@@ -352,7 +352,9 @@ string const BufferParams::readToken(LyX
// Update also the LColor table:
if (color == "none")
color = lcolor.getX11Name(LColor::background);
- lcolor.setColor(lcolor.getFromLyXName(branch), color);
+ //lcolor.setColor(lcolor.getFromLyXName(branch),
color);
+ lcolor.setColor(branch, color);
+
}
}
} else if (token == "\\author") {
pgp0.pgp
Description: PGP signature
Re: "Branch: titlepage" gets read as color?
Angus Leeming <[EMAIL PROTECTED]> writes: | The maximum positive integer that can fit into an int is 0x7fff or | 2^(32)-1. And before you tell me that enum is unsigned, it isn't. I think we can force it to be. What does the standard say about enums again? -- Lgb
Re: "Branch: titlepage" gets read as color?
Lars Gullik Bjønnes wrote:
>>> | Angus> Looking at debug.h, I think we've run out of space in the
>>> | Angus> lyx_debug_trai::type enum. 2^24 > 0xff (by 1 ;-)
>>>
>>> we should be able to go to 2^32. (or at least 31)
>>
> | In that case, (and I agree), shouldn't ANY be reset:
>>
> | ANY = 0xff
> | 2^(32)-1 == 0x7fff
>>
> | ???
>
> Then ANY is missing a byte.
>
> any should be:
>
> ANY = 0x
Really? Why?
Try this:
#include
int main()
{
int const ANY = 0x7fff+1;
std::cout << "ANY == " << ANY << std::endl;
return 0;
}
Then remove the '+1'.
Saving you the bother:
With the '+1'
$ ./trial
ANY == -2147483648
Without the '+1'
$ ./trial
ANY == 2147483647
The maximum positive integer that can fit into an int is 0x7fff or
2^(32)-1. And before you tell me that enum is unsigned, it isn't.
#include
int main()
{
enum { ANY = 0x7fff+1 };
std::cout << "ANY == " << ANY << std::endl;
return 0;
}
Results are identical to those for an int.
--
Angus
Re: "Branch: titlepage" gets read as color?
Angus Leeming <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: >> | Angus> Looking at debug.h, I think we've run out of space in the >> | Angus> lyx_debug_trai::type enum. 2^24 > 0xff (by 1 ;-) >> >> we should be able to go to 2^32. (or at least 31) > | In that case, (and I agree), shouldn't ANY be reset: > | ANY = 0xff | 2^(32)-1 == 0x7fff > | ??? Then ANY is missing a byte. any should be: ANY = 0x -- Lgb
Re: "Branch: titlepage" gets read as color?
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Yes, this sounds good. I did this, calling the creating
Martin> function LColor::getFromLyXNameOrAdd(). Not a splendid choice,
Martin> but...
Jean-Marc> This is not exactly what I had in mind, but rather
Jean-Marc> something like the patch below (which is completely
Jean-Marc> untested). I think it is better since it is never possible
Jean-Marc> to create a new color entry that is not associated to a
Jean-Marc> x11name. And I think the semantics look good.
Umph. Here is the patch.
JMarc
Index: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.1840
diff -u -p -r1.1840 ChangeLog
--- src/ChangeLog 23 Mar 2004 14:39:40 - 1.1840
+++ src/ChangeLog 23 Mar 2004 16:02:43 -
@@ -1,3 +1,10 @@
+2004-03-23 Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
+
+ * lyxfunc.C (dispatch): use the new LColor::setColor
+
+ * LColor.C (setColor): new version that takes two strings as
+ argument and creates a new color entry if necessary
+
2004-03-23 Angus Leeming <[EMAIL PROTECTED]>
* ispell.C (LaunchIspell):
Index: src/LColor.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/LColor.C,v
retrieving revision 1.51
diff -u -p -r1.51 LColor.C
--- src/LColor.C 18 Mar 2004 15:49:44 - 1.51
+++ src/LColor.C 23 Mar 2004 16:02:43 -
@@ -229,6 +229,21 @@ bool LColor::setColor(LColor::color col,
}
+bool LColor::setColor(string const & lyxname, string const &x11name)
+{
+ string const lcname = ascii_lowercase(lyxname);
+ if (pimpl_->transform.find(lcname) == pimpl_->transform.end()) {
+ lyxerr[Debug::GUI]
+ << "LColor::setColor: Unknown color \""
+ << lyxname << '"' << endl;
+ addColor(static_cast(pimpl_->infotab.size()), lcname);
+ }
+
+ return setColor(static_cast(pimpl_->transform[lcname]),
+ x11name);
+}
+
+
LColor::color LColor::getFromGUIName(string const & guiname) const
{
Pimpl::InfoTab::const_iterator it = pimpl_->infotab.begin();
@@ -254,7 +269,7 @@ LColor::color LColor::getFromLyXName(str
if (pimpl_->transform.find(lcname) == pimpl_->transform.end()) {
lyxerr << "LColor::getFromLyXName: Unknown color \""
<< lyxname << '"' << endl;
- addColor(static_cast(pimpl_->infotab.size()), lcname);
+ return none;
}
return static_cast(pimpl_->transform[lcname]);
Index: src/LColor.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/LColor.h,v
retrieving revision 1.40
diff -u -p -r1.40 LColor.h
--- src/LColor.h 14 Dec 2003 16:33:51 - 1.40
+++ src/LColor.h 23 Mar 2004 16:02:43 -
@@ -198,6 +198,12 @@ public:
*/
bool setColor(LColor::color col, std::string const & x11name);
+ /** set the given LyX color to the color defined by the X11
+ * name given \returns true if successful. A new color entry
+ * is created if the color is unknown
+ */
+ bool setColor(std::string const & lyxname, std::string const & x11name);
+
/// Get the GUI name of \c color.
std::string const getGUIName(LColor::color c) const;
Index: src/lyxfunc.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxfunc.C,v
retrieving revision 1.586
diff -u -p -r1.586 lyxfunc.C
--- src/lyxfunc.C 23 Mar 2004 11:22:11 - 1.586
+++ src/lyxfunc.C 23 Mar 2004 16:02:43 -
@@ -1072,8 +1072,7 @@ void LyXFunc::dispatch(FuncRequest const
(lyx_name == lcolor.getLyXName(LColor::graphicsbg) &&
x11_name != lcolor.getX11Name(LColor::graphicsbg));
- LColor::color col = lcolor.getFromLyXName(lyx_name);
- if (!lcolor.setColor(col, x11_name)) {
+ if (!lcolor.setColor(lyx_name, x11_name)) {
setErrorMessage(
bformat(_("Set-color \"%1$s\" failed "
"- color is undefined or "
Re: "Branch: titlepage" gets read as color?
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: Martin> Yes, this sounds good. I did this, calling the creating Martin> function LColor::getFromLyXNameOrAdd(). Not a splendid choice, Martin> but... This is not exactly what I had in mind, but rather something like the patch below (which is completely untested). I think it is better since it is never possible to create a new color entry that is not associated to a x11name. And I think the semantics look good. JMarc
Re: "Branch: titlepage" gets read as color?
On Mon, Mar 22, 2004 at 05:47:31PM +0100, Jean-Marc Lasgouttes spake thusly:
> > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> Martin Vermeer wrote:
> >> On Mon, Mar 22, 2004 at 09:12:56AM +, Angus Leeming spake
> >> thusly:
> >>
> >>> > > Should this be made more clearly a warning or info message?
> >>> Like > "... Color \"" << lyxname << '"' added to color table" <<
> >>> endl ?
> >>>
> >>> Yes. That is exactly what the code is doing, after all. Moreover,
> >>> I think that the warning should be output in debug mode only.
> >>>
> >>> lyxerr[your debug flavour] << ...;
> >> Yes, which flavour? COLOR?
>
> Angus> Looking at debug.h, I think we've run out of space in the
> Angus> lyx_debug_trai::type enum. 2^24 > 0xff (by 1 ;-)
>
> Angus> So, I'd suggest using GUI for your purposes. Maybe we should
> Angus> consider culling some of the redundant warning levels?
>
> For this particular case, I'd rather see the branch code use a
> different code path in LColor, so that other code that calls
> LColor::getFromLyXName with a bogus name triggers the warning always.
> This particular use of the method by the branch code triggered a
> change in the semantics that does not fit the other functions...
>
> What about having a new LColor::setColor(lyxname, x11name) that
> creates the new color when needed?
>
> Then the code that creates new color entries in LColor::getFromLyXName
> could be removed and everybody would be happy.
Yes, this sounds good. I did this, calling the creating function
LColor::getFromLyXNameOrAdd(). Not a splendid choice, but...
Now that we are getting around to cleaning this up, I ran into another
interesting problem: text (character) colours have the default value
"default", which does not exist in the LColor table. The code will
crash on it. I added a fix into lyxfont.C, ugly for now:
622 // Necessary because "default" is in .lyx file format but not in
623 // LColor -- MV 23.3.2004:
624 if (col == "default")
625 setColor(lcolor.getFromLyXName("inherit"));
626 else
627 setColor(lcolor.getFromLyXName(col));
It mirrors what happens later on in lyxfont.C:
744 // To make us file compatible with older
745 // lyx versions we emit "default" instead
746 // of "inherit"
747 string col_str(lcolor.getLyXName(color()));
748 if (col_str == "inherit") col_str = "default";
Carrying coals to Newcastle and back again. With a heavy heart I
propose to change the .lyx format so, that instead of \color default
we use \color inherit or \color none [which of the two would be more
appropriate?]
Extending the size of the debug flags later.
- Martin
Index: LColor.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/LColor.C,v
retrieving revision 1.51
diff -u -p -r1.51 LColor.C
--- LColor.C18 Mar 2004 15:49:44 - 1.51
+++ LColor.C23 Mar 2004 15:14:24 -
@@ -252,11 +252,19 @@ LColor::color LColor::getFromLyXName(str
{
string const lcname = ascii_lowercase(lyxname);
if (pimpl_->transform.find(lcname) == pimpl_->transform.end()) {
- lyxerr << "LColor::getFromLyXName: Unknown color \""
+ lyxerr[Debug::GUI] << "LColor::getFromLyXName: Unknown color \""
<< lyxname << '"' << endl;
- addColor(static_cast(pimpl_->infotab.size()), lcname);
- }
+ BOOST_ASSERT(false);
+ } else
+ return static_cast(pimpl_->transform[lcname]);
+}
+
+LColor::color LColor::getFromLyXNameOrAdd(string const & lyxname) const
+{
+ string const lcname = ascii_lowercase(lyxname);
+ if (pimpl_->transform.find(lcname) == pimpl_->transform.end())
+ addColor(static_cast(pimpl_->infotab.size()), lcname);
return static_cast(pimpl_->transform[lcname]);
}
Index: LColor.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/LColor.h,v
retrieving revision 1.40
diff -u -p -r1.40 LColor.h
--- LColor.h14 Dec 2003 16:33:51 - 1.40
+++ LColor.h23 Mar 2004 15:14:24 -
@@ -214,6 +214,8 @@ public:
LColor::color getFromGUIName(std::string const & guiname) const;
/// \returns the LColor::color associated with the LyX name.
LColor::color getFromLyXName(std::string const & lyxname) const;
+ /// \same, but creates color table entry if necessary.
+ LColor::color getFromLyXNameOrAdd(std::string const & lyxname) const;
private:
///
void addColor(LColor::color c, std::string const & lyxname) const;
Index: bufferparams.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/bufferparams.C,v
retrieving revision 1.77
diff -u -p -r1.77 bufferparams.C
--- bufferparams.C 7 Mar 2004 14:33:17
Re: "Branch: titlepage" gets read as color?
Lars Gullik Bjønnes wrote: > | Angus> Looking at debug.h, I think we've run out of space in the > | Angus> lyx_debug_trai::type enum. 2^24 > 0xff (by 1 ;-) > > we should be able to go to 2^32. (or at least 31) In that case, (and I agree), shouldn't ANY be reset: ANY = 0xff 2^(32)-1 == 0x7fff ??? -- Angus
Re: "Branch: titlepage" gets read as color?
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: >> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > | Angus> Martin Vermeer wrote: >>> On Mon, Mar 22, 2004 at 09:12:56AM +, Angus Leeming spake >>> thusly: >>> > > Should this be made more clearly a warning or info message? Like > "... Color \"" << lyxname << '"' added to color table" << endl ? Yes. That is exactly what the code is doing, after all. Moreover, I think that the warning should be output in debug mode only. lyxerr[your debug flavour] << ...; >>> Yes, which flavour? COLOR? > | Angus> Looking at debug.h, I think we've run out of space in the | Angus> lyx_debug_trai::type enum. 2^24 > 0xff (by 1 ;-) we should be able to go to 2^32. (or at least 31) -- Lgb
Re: "Branch: titlepage" gets read as color?
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Martin Vermeer wrote: >> On Mon, Mar 22, 2004 at 09:12:56AM +, Angus Leeming spake >> thusly: >> >>> > > Should this be made more clearly a warning or info message? >>> Like > "... Color \"" << lyxname << '"' added to color table" << >>> endl ? >>> >>> Yes. That is exactly what the code is doing, after all. Moreover, >>> I think that the warning should be output in debug mode only. >>> >>> lyxerr[your debug flavour] << ...; >> Yes, which flavour? COLOR? Angus> Looking at debug.h, I think we've run out of space in the Angus> lyx_debug_trai::type enum. 2^24 > 0xff (by 1 ;-) Angus> So, I'd suggest using GUI for your purposes. Maybe we should Angus> consider culling some of the redundant warning levels? For this particular case, I'd rather see the branch code use a different code path in LColor, so that other code that calls LColor::getFromLyXName with a bogus name triggers the warning always. This particular use of the method by the branch code triggered a change in the semantics that does not fit the other functions... What about having a new LColor::setColor(lyxname, x11name) that creates the new color when needed? Then the code that creates new color entries in LColor::getFromLyXName could be removed and everybody would be happy. JMarc
Re: "Branch: titlepage" gets read as color?
Martin Vermeer wrote: > On Mon, Mar 22, 2004 at 09:12:56AM +, Angus Leeming spake > thusly: > >> > >> > Should this be made more clearly a warning or info message? Like >> > "... Color \"" << lyxname << '"' added to color table" << endl ? >> >> Yes. That is exactly what the code is doing, after all. Moreover, I >> think that the warning should be output in debug mode only. >> >> lyxerr[your debug flavour] << ...; > > Yes, which flavour? COLOR? Looking at debug.h, I think we've run out of space in the lyx_debug_trai::type enum. 2^24 > 0xff (by 1 ;-) So, I'd suggest using GUI for your purposes. Maybe we should consider culling some of the redundant warning levels? -- Angus
Re: "Branch: titlepage" gets read as color?
On Mon, Mar 22, 2004 at 09:12:56AM +, Angus Leeming spake thusly: > > > > Should this be made more clearly a warning or info message? Like > > "... Color \"" << lyxname << '"' added to color table" << endl ? > > Yes. That is exactly what the code is doing, after all. Moreover, I > think that the warning should be output in debug mode only. > > lyxerr[your debug flavour] << ...; Yes, which flavour? COLOR? - Martin pgp0.pgp Description: PGP signature
Re: "Branch: titlepage" gets read as color?
Martin Vermeer wrote:
> On Sun, Mar 21, 2004 at 01:27:21PM -0800, Kayvan A. Sylvan spake
> thusly:
>
>> I have a lyx document with a branch called "titlepage" (for when I
>> want to turn a custom titlepage off or on).
>>
>> When LyX reads it, I see:
>>
>> no text in updateScrollbar
>> Buffer::Buffer()
>> LColor::getFromLyXName: Unknown color "titlepage"
> 251 LColor::color LColor::getFromLyXName(string const & lyxname)
> const
> 252 {
> 253 string const lcname = ascii_lowercase(lyxname);
> 254 if (pimpl_->transform.find(lcname) ==
> pimpl_->transform.end()) {
> 255 lyxerr << "LColor::getFromLyXName: Unknown color \""
> 256<< lyxname << '"' << endl;
> 257 addColor(static_cast(pimpl_->infotab.size()),
> lcname);
> 258 }
> 259
> 260 return
> static_cast(pimpl_->transform[lcname]); 261 }
>
> As you see, this is only a warning that the colour isn't yet in the
> registry, and then it is added.
>
> Should this be made more clearly a warning or info message? Like
> "... Color \"" << lyxname << '"' added to color table" << endl ?
Yes. That is exactly what the code is doing, after all. Moreover, I
think that the warning should be output in debug mode only.
lyxerr[your debug flavour] << ...;
--
Angus
Re: "Branch: titlepage" gets read as color?
On Sun, Mar 21, 2004 at 01:27:21PM -0800, Kayvan A. Sylvan spake thusly:
> I have a lyx document with a branch called "titlepage" (for when I want
> to turn a custom titlepage off or on).
>
> When LyX reads it, I see:
>
> no text in updateScrollbar
> Buffer::Buffer()
> LColor::getFromLyXName: Unknown color "titlepage"
>
> It does not seem to affect branch function, however.
I can confirm this... but it is harmless. And no, your suspicion is wrong.
It seems to come from bufferparams.C:355:
346 // not yet operational
347 if (tok == "\\color") {
348 lex.nextToken();
349 string color = lex.getString();
350 if (branch_ptr)
351 branch_ptr->setColor(color);
352 // Update also the LColor table:
353 if (color == "none")
354 color = lcolor.getX11Name(LColor::background);
355 lcolor.setColor(lcolor.getFromLyXName(branch),
color);
356 }
and LColor.C:
251 LColor::color LColor::getFromLyXName(string const & lyxname)
const
252 {
253 string const lcname = ascii_lowercase(lyxname);
254 if (pimpl_->transform.find(lcname) == pimpl_->transform.end()) {
255 lyxerr << "LColor::getFromLyXName: Unknown color \""
256<< lyxname << '"' << endl;
257 addColor(static_cast(pimpl_->infotab.size()), lcname);
258 }
259
260 return static_cast(pimpl_->transform[lcname]);
261 }
As you see, this is only a warning that the colour isn't yet in the
registry, and then it is added.
Should this be made more clearly a warning or info message? Like
"... Color \"" << lyxname << '"' added to color table" << endl ?
- Martin
pgp0.pgp
Description: PGP signature
"Branch: titlepage" gets read as color?
I have a lyx document with a branch called "titlepage" (for when I want to turn a custom titlepage off or on). When LyX reads it, I see: no text in updateScrollbar Buffer::Buffer() LColor::getFromLyXName: Unknown color "titlepage" It does not seem to affect branch function, however. -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92)
