Re: The DEPM discussion
John Levon wrote: > Possibly but then we're not far away from being back in DEPM land anyway > in terms of complexity (since you have to keep the cursor row stable). I'm not so sure. I think it's a matter of putting the reference row to the cursor row (instead of the top row) if it's visible, on LyXText::top_y(int) and/or update it on setCursor(). I think it's a sane thing to do in all cases, the cursor row should be the most stable anyway if it's visible, no? > I wonder if I get get some more support for my favoured solution if I > implemented more bits of paragraph-pruning. I think that it reasonably ortonormal. We need the par pruning anyway for all three solution (yours, martin's and mine). Am I right? PS: I'm delaying the mutable/const patch until we decide what to do. There are too many patches in the air for the same files and it's not 'urgent'. Alfredo
Re: [PATCH] GCC 3.3 warnings.
Andre Poenitz <[EMAIL PROTECTED]> writes: | I must have missed some point. Yes. -- Lgb
Re: File loading error.
On Wed, Mar 12, 2003 at 08:17:45PM +, John Levon wrote: > On Wed, Mar 12, 2003 at 09:13:56PM +0100, Lars Gullik Bj?nnes wrote: > > > The error: > > "Textclass error > > Document uses an unknown textclass 'Standard'.-- substituting" > > > > Can this be the last paragraph changes? > > Add "\end_header" to the end of the header. I didn't bother bumping the > format because we already bumped it for the change tracking stuff. The rule is to bump the format number for _every_ change. Believe it or not, some people actually _use_ LyX. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: [PATCH] GCC 3.3 warnings.
Andre Poenitz <[EMAIL PROTECTED]> writes: | On Wed, Mar 12, 2003 at 07:34:02PM +0100, Lars Gullik Bjønnes wrote: | > This patch fixes some GCC 3.3 warnings. If this is the best way to do | > it can be argued. | > | > Comments? | | I don't like it. | | If anything at all I'd accept a functions style cast | |char c; |foo[int(c)]; I saw another fix proposed at the boost list: Use [0 + c] to force integer promotion. Also as been mentioned on this list, why use direct setting of the arrat anyway? Why not use the "setter" function already provided for this? | but we'd better look for a way to disable that warning in the compiler. No I don't agree. Perfectly valid warning, it is only strange in this specific case since 'a' is used and that cannot be wrong... 'å' on the other hand... -- Lgb
Re: [PATCH] GCC 3.3 warnings.
On Wed, Mar 12, 2003 at 07:09:23PM +, Angus Leeming wrote:
> -theCatcode['&'] = catAlign;
> +theCatcode[static_cast('\\')] = catEscape;
>
> Why not:
>
> setCatcode('&', catAlign);
Because that's simply assigning a value to an array element.
I ordinarily do not use a function for that.
> void setCatcode(char c, CATCODETYPE val) {
> theCatcode[static_cast(c)] = val;
> }
Hm. Might be an option. But I still don't like it. We complicate code
(_correct code_, no less!) just to make some compiler happy. If this were
MSVC++ 6.0 or Sun whatever everbody would start cursing.
For bleeding edge g++ we'd cut our legs off.
I must have missed some point.
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Re: [PATCH] GCC 3.3 warnings.
On Wed, Mar 12, 2003 at 07:34:02PM +0100, Lars Gullik Bjønnes wrote: > This patch fixes some GCC 3.3 warnings. If this is the best way to do > it can be argued. > > Comments? I don't like it. If anything at all I'd accept a functions style cast char c; foo[int(c)]; but we'd better look for a way to disable that warning in the compiler. The code is completely legal and well-defined as it is right now and I see no reason to bloat the code to doubled size. This makes reading and understanding pretty hard. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: [PATCH] InsetNewline
Andre Poenitz <[EMAIL PROTECTED]> writes: | On Wed, Mar 12, 2003 at 06:02:34PM +0100, Lars Gullik Bjønnes wrote: | > You use one wrong construct: "new InsetNewline()" | > that should be: "new InsetNewline" (remvoe the parenthesis) | | I like the latter more, too, but I think in this case it is equivalent | (assuming that it compiles at all) Actually I belive they are not really equivalent, let's see if I can dig out my the reason from my references. (I seem to be missing a book or two... I'll come back to this one later.) -- Lgb
Re: [patch] env2.diff
On Wed, Mar 12, 2003 at 06:43:27PM +0100, Lars Gullik Bjønnes wrote: > | Lars won't thank you for this ;-) > > Mmmm... I expect that was a fluke... Indeed. I started off with the wrong "template". Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: [patch] env2.diff
On Wed, Mar 12, 2003 at 06:29:36PM +0100, Jean-Marc Lasgouttes wrote: > Seconded. I can accept to see new features arriving and some temporary > breaking, but if andre' already lost interest in making bibitem work > _properly_, then I am worried. Bibliography is one of the "environment style" insets. So no, this is not forgotten. > I will certainly disagree with removing of current code until andre > can prove us that his new code can be at least as useful. I did not remove anything at all in this case. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: [PATCH] InsetNewline
On Wed, Mar 12, 2003 at 06:02:34PM +0100, Lars Gullik Bjønnes wrote: > You use one wrong construct: "new InsetNewline()" > that should be: "new InsetNewline" (remvoe the parenthesis) I like the latter more, too, but I think in this case it is equivalent (assuming that it compiles at all) Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Paragraph dialog patch
For info/review: John's ParagraphParameter::read and write methods have been put to speedy use ;-) Here is the Paragraph dialog receiving its data as a string and returning it to dispatch(). Behaviour of the dialog is unchanged but everything is now controlled by the kernel. I have one question: is ParagraphParameters.[Ch] the correct place for setParagraphParams and params2string(Paragraph const &, sting &) ? -- Angus paragraph.diff.gz Description: GNU Zip compressed data
Re: [Patch (New)] Fix and prettify Xforms Changes dialog.
John Levon wrote: > On Tue, Mar 11, 2003 at 08:56:21AM +0900, Rob Lahaye wrote: > > >>Actually, this problem occurs when two documents are in the buffer >>and Changes-tracking is used. Somehow, the Changes features does not >>work well when there's more than one document is in the buffer >>(or another had been loaded prior to the current document!). > > Yes, well spotted. All should be OK now, hopefully. YES! Indeed fixed. Could you then please finally apply my patch to Xforms/Changes dialog, since this crash was apparently was not caused by the patch. The patch is against current CVS (against Angus' latest changes). Please apply. The ChangeLog is not included in the patch; therefore: --- src/frontends/controllers/ChangeLog: 2003-03-13 Rob Lahaye <[EMAIL PROTECTED]> * ControlChanges.[Ch]: ControlChanges::find() returns the bool from lyxfind::findNextChange(), instead of void. --- src/frontends/xforms/ChangeLog: 2003-03-13 Rob Lahaye <[EMAIL PROTECTED]> * FormChanges.C: "LyX: " in dialog's name is redundant; add few comments; fix disabling buttons when no changes found. * forms/form_changes.fd: prettify layout. --- Regards, Rob. ChangesDialog.diff.gz Description: application/gzip
Re: horizontal cursor
On Tue, 11 Mar 2003, Alfredo Braunstein wrote: > Alfredo I put some screenshots of different cursors here: http://www.md.kth.se/~chr/lyx/test/horizontal_cursor/screenshots/ but I'm not that happy with them. And it's difficult to get the blinking effect... The document in the background ought to have more than just standard paragraph types as well. /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Cygwin patch, reworked
Here is a good, self-contained patch, touching only the build mechanism. Please apply, and "cvs add" config/cygwin.m4 -- 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) ? config/cygwin.m4 Index: ChangeLog === RCS file: /cvs/lyx/lyx-devel/ChangeLog,v retrieving revision 1.924 diff -u -r1.924 ChangeLog --- ChangeLog 2003/03/08 13:47:20 1.924 +++ ChangeLog 2003/03/13 01:00:11 @@ -1,3 +1,7 @@ +2003-03-12 Kayvan Sylvan <[EMAIL PROTECTED]> + + * autogen.sh (ACINCLUDE_FILES): Added cygwin.m4 + 2003-03-08 Lars Gullik Bjønnes <[EMAIL PROTECTED]> * add bogus entry Index: autogen.sh === RCS file: /cvs/lyx/lyx-devel/autogen.sh,v retrieving revision 1.43 diff -u -r1.43 autogen.sh --- autogen.sh 2003/02/11 13:07:37 1.43 +++ autogen.sh 2003/03/13 01:00:11 @@ -4,7 +4,7 @@ AUTOHEADER="autoheader" AUTOMAKE="automake -a -c --foreign" AUTOCONF="autoconf" -ACINCLUDE_FILES="lyxinclude.m4 libtool.m4 codeset.m4 gettext.m4 glibc21.m4 iconv.m4 isc-posix.m4 lcmessage.m4 progtest.m4 xforms.m4 qt.m4 gtk--.m4 gnome--.m4 gnome.m4 pspell.m4 pkg.m4" +ACINCLUDE_FILES="lyxinclude.m4 libtool.m4 codeset.m4 gettext.m4 glibc21.m4 iconv.m4 isc-posix.m4 lcmessage.m4 progtest.m4 xforms.m4 qt.m4 gtk--.m4 gnome--.m4 gnome.m4 pspell.m4 cygwin.m4 pkg.m4" # Discover what version of autoconf we are using. autoversion=`$AUTOCONF --version | head -n 1` Index: config/ChangeLog === RCS file: /cvs/lyx/lyx-devel/config/ChangeLog,v retrieving revision 1.95 diff -u -r1.95 ChangeLog --- config/ChangeLog2003/03/10 19:18:42 1.95 +++ config/ChangeLog2003/03/13 01:00:42 @@ -1,3 +1,15 @@ +2003-03-12 Kayvan Sylvan <[EMAIL PROTECTED]> + + * configure.ac configure.in: Add the CHECK_WITH_CYGWIN macro call. + + * Makefile.am: add cygwin.m4 to EXTRA_DIST + + * cygwin.m4: Add CHECK_WITH_CYGWIN function to encapuslate + some checks for Win32 GCC based on info from the following URL: + http://bugzilla.gnome.org/showattachment.cgi?attach_id=12253 + + * libtool.m4: TAB to SPACE fixes. Now impgen.c compiles on Cygwin. + 2003-03-10 Lars Gullik Bjønnes <[EMAIL PROTECTED]> * pspell.m4: simplify pspell checking even more Index: config/Makefile.am === RCS file: /cvs/lyx/lyx-devel/config/Makefile.am,v retrieving revision 1.7 diff -u -r1.7 Makefile.am --- config/Makefile.am 2003/02/18 18:00:51 1.7 +++ config/Makefile.am 2003/03/13 01:00:42 @@ -4,4 +4,4 @@ lyxinclude.m4 lyxinclude25x.m4 lyxinclude213.m4 \ glibc21.m4 iconv.m4 isc-posix.m4 lcmessage.m4 progtest.m4 \ qt.m4 gtk--.m4 gnome--.m4 gnome.m4 pkg.m4 xforms.m4 pspell.m4 \ - relyx_configure.ac relyx_configure.in + relyx_configure.ac relyx_configure.in cygwin.m4 Index: config/configure.ac === RCS file: /cvs/lyx/lyx-devel/config/configure.ac,v retrieving revision 1.32 diff -u -r1.32 configure.ac --- config/configure.ac 2003/03/10 14:28:14 1.32 +++ config/configure.ac 2003/03/13 01:00:42 @@ -131,6 +131,9 @@ ### Check if we want pspell libraries CHECK_WITH_PSPELL +### Check for some Cygwin-specific details. +CHECK_WITH_CYGWIN + ### Check for X libraries # The real thing. AC_PATH_XTRA Index: config/configure.in === RCS file: /cvs/lyx/lyx-devel/config/configure.in,v retrieving revision 1.25 diff -u -r1.25 configure.in --- config/configure.in 2003/03/10 14:28:14 1.25 +++ config/configure.in 2003/03/13 01:00:43 @@ -134,6 +134,9 @@ ### Check if we want pspell libraries CHECK_WITH_PSPELL +### Check for some Cygwin-specific details. +CHECK_WITH_CYGWIN + ### Check for X libraries # The real thing. AC_PATH_XTRA Index: config/libtool.m4 === RCS file: /cvs/lyx/lyx-devel/config/libtool.m4,v retrieving revision 1.5 diff -u -r1.5 libtool.m4 --- config/libtool.m4 2002/08/14 11:24:22 1.5 +++ config/libtool.m4 2003/03/13 01:00:58 @@ -2737,44 +2737,44 @@ # # dll = open(filename, O_RDONLY|O_BINARY); # if (dll < 1) -# return 1; +# return 1; # # dll_name = filename; # # for (i=0; filename[i]; i++) -# if (filename[i] == '/' || filename[i] == '\\' || filename[i] == ':') -# dll_name = filename + i +1; +# if (filename[i] == '/' || filename[i] == '\\' || filename[i] == ':') +# dll_name = filename + i +1; # # pe_header_offset = pe_get32 (dll, 0x3c); # opthdr_ofs = pe_header_offset + 4 + 20; #
Re: [PATH] dont allow getChar(par->size()) (was: [PATCH] InsetNewline)
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| I just saw that there are problems with new documents, I'll look at
| that shortly.
Update: this allows creating new docs as well. It is now close to
something I'd like to apply.
Index: src/lyxrow.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxrow.C,v
retrieving revision 1.18
diff -u -p -r1.18 lyxrow.C
--- src/lyxrow.C 11 Mar 2003 11:52:04 - 1.18
+++ src/lyxrow.C 13 Mar 2003 00:50:31 -
@@ -159,6 +159,9 @@ namespace {
bool nextRowIsAllInset(Row const & row, pos_type last)
{
+ if (last + 1 >= row.par()->size())
+ return false;
+
if (!row.par()->isInset(last + 1))
return false;
@@ -192,7 +195,7 @@ int Row::numberOfSeparators() const
pos_type p = max(pos(), par()->beginningOfBody());
int n = 0;
- for (; p <= last; ++p) {
+ for (; p < last; ++p) {
if (par()->isSeparator(p)) {
++n;
}
@@ -208,7 +211,7 @@ int Row::numberOfHfills() const
// hfill *DO* count at the beginning of paragraphs!
if (first) {
- while (first <= last && par()->isHfill(first)) {
+ while (first < last && par()->isHfill(first)) {
++first;
}
}
@@ -218,8 +221,8 @@ int Row::numberOfHfills() const
int n = 0;
// last, because the end is ignored!
- for (pos_type p = first; p <= last; ++p) {
+ for (pos_type p = first; p < last; ++p) {
if (par()->isHfill(p))
++n;
}
Index: src/paragraph_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/paragraph_pimpl.C,v
retrieving revision 1.53
diff -u -p -r1.53 paragraph_pimpl.C
--- src/paragraph_pimpl.C 12 Mar 2003 19:16:40 - 1.53
+++ src/paragraph_pimpl.C 13 Mar 2003 00:50:32 -
@@ -252,12 +252,14 @@ void Paragraph::Pimpl::rejectChange(pos_
Paragraph::value_type Paragraph::Pimpl::getChar(pos_type pos) const
{
- // This is in the critical path for loading!
- pos_type const siz = size();
- lyx::Assert(pos <= siz);
+ //lyx::Assert(pos <= siz);
// This is stronger, and I belive that this is the assertion
// that we should really use. (Lgb)
- //Assert(pos < size());
+ lyx::Assert(pos < size());
+
+#if 0
+ // This is in the critical path for loading!
+ pos_type const siz = size();
// Then this has no meaning. (Lgb)
if (!siz || pos == siz) {
@@ -266,7 +268,7 @@ Paragraph::value_type Paragraph::Pimpl::
<< " is a bit silly !" << endl;
return '\0';
}
-
+#endif
return text[pos];
}
Index: src/rowpainter.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/rowpainter.C,v
retrieving revision 1.4
diff -u -p -r1.4 rowpainter.C
--- src/rowpainter.C 12 Mar 2003 19:16:40 - 1.4
+++ src/rowpainter.C 13 Mar 2003 00:50:33 -
@@ -312,7 +312,8 @@ bool RowPainter::paintBackground()
Inset const * inset = 0;
if (!bv_.screen().forceClear() && last == row_.pos()
- && par_.isInset(row_.pos())) {
+ && row_.pos() < par_.size()
+ && par_.isInset(row_.pos())) {
inset = par_.getInset(row_.pos());
clear_area = inset->doClearArea();
}
@@ -897,6 +898,11 @@ bool RowPainter::paintText()
if (x_ > bv_.workWidth())
break;
pos_type pos = text_.vis2log(vpos);
+
+ if (pos >= par_.size()) {
+ ++vpos;
+ continue;
+ }
if (x_ + singleWidth(pos) < 0) {
x_ += singleWidth(pos);
Index: src/text.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text.C,v
retrieving revision 1.309
diff -u -p -r1.309 text.C
--- src/text.C 12 Mar 2003 23:19:09 - 1.309
+++ src/text.C 13 Mar 2003 00:50:34 -
@@ -206,6 +206,9 @@ unsigned char LyXText::transformChar(uns
int LyXText::singleWidth(BufferView * bview, Paragraph * par,
pos_type pos) const
{
+ if (pos >= par->size())
+ return 0;
+
char const c = par->getChar(pos);
return singleWidth(bview, par, pos, c);
}
@@ -214,6 +217,9 @@ int LyXText::singleWidth(BufferView * bv
int LyXText::singleWidth(BufferView * bview, Paragraph * par,
pos_type pos, char c) const
{
+ if (pos >= par->size())
+ return 0;
+
LyXFont const font = getFont(bview->buffer(), par, pos);
// The most common case is handled first (Asger)
@@ -422,10 +428,12 @@ bool LyXText::isBoundary(Buffer const *
int LyXText::leftMargin(BufferView * bview, Row const * row) const
{
Inset * ins;
- if ((row->par()->getChar(row->pos()) == Paragraph::META_INSET) &&
- (ins=row->par()->getInset(row->pos())) &&
- (ins->needFullRow() || ins->display()))
- return LEFT_MARGIN;
+
+ if (row->pos() < row->par()->size())
+ if ((row->par()->getChar(row->pos()) == Paragraph::META_INSET) &&
+ (ins = row->par()->getInset(row->pos())) &&
+ (ins->needFullRow() || ins->display()))
+ return LEFT_MARGIN;
LyXTextClass const & tclass =
bview->buffer()->params.getLyXTextClass();
@@ -615,10 +623,12 @@ int LyXText::leftMargin(BufferView * bvi
int LyXText::rightMargin(Buffer
Re: The DEPM discussion
On Wed, 12 Mar 2003, John Levon wrote: > On Wed, Mar 12, 2003 at 09:45:29PM +0100, Christian Ridderstr?m wrote: > > > I agree with that... and I wonder how my behaviour that I described above > > would change using it? > > It would break > duh... you mean my brain would go "clonk" :-) You've been coding too much lately... No seriously, I was wondering if I'd still go to where I want to insert stuff first, press enter and get the h.cursor and then go copy the text. Or if I'd stop doing that. And if I stop doing that, would there be any "penalty"? Would it hamper creativity or whatever? /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: The DEPM discussion
On Wed, 12 Mar 2003, Alfredo Braunstein wrote: > Christian Ridderström wrote: > > > Here's a new idea (dare I say "novel" ;-) > > > > Give empty paragraphs (and empty double spaces) a visual marker, for > > instance a different background colour? Flashing background? Animations of > > a black hole? Ok... maybe just a different background, light gray? > > > > This visual marker informs the user that the space will not appear in > > the output. "Purging" the DEPMs could even be optional at save. > > £$%£&! Interesting language, I've never seen that ... smiley?... before. I've never used the word "novel" to describe an idea I've had before - boy am I glad I didn't do this in a paper.. it's embarrasing > From my original post on the subject: > > |Proposal 1) Plain forbid 3 spaces / 2 empty paragraphs (in order to > |discourage space/newline formatting abuse, do not load nor save double > |spaces, empty paragraphs). > | > |Proposal 2) Mark double/triple/... spaces and empty pars with some > |disgusting mark or colour, to encourage their removal. Can be combined with > |1) > > John even criticized it, and I agree with him. Sorry... I'll be a good boy and go back and read John's criticism... btw, I wasn't suggesting a disgusting mark... more sort of: "hey, here you left an empty paragraph because you want to add something" - sort of like the comment environment in that sense. /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: Math macros updating
On Wed, 12 Mar 2003, Andre Poenitz wrote: > On Wed, Mar 12, 2003 at 10:41:09AM -0500, Aleksandar Donev wrote: > > I have noticed a feature of LyX which is very nice, but also > > undocumented (as far as I can tell) and sometimes may be in the way, and > > want to mention it. I have two papers open in LyX which have almost > > identical math-macro definitions in them. When I modify the "display" > > (i.e. second box) contents in one of the papers, the corresponding > > math-macro in the other paper somehow automatically gets updated. > > This is not a feature, this is a plain bug. Unfortunately, we are currently > not in a position to fix this properly. > > Math Macros are LyX-global, not buffer specific. Could you "use" this bug? I.e. have a separate lyx document with lots of macro definitions, and then put a reminder in the beginning of your real document saying: "Always open macros.lyx, before using this document!!!" This way you "wouldn't" have to store the macros in the lyx document? (I know this is probably a bad idea, but I was just wondering) /Christian -- Christian Ridderström http://www.md.kth.se/~chr
[PATH] dont allow getChar(par->size()) (was: [PATCH] InsetNewline)
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| I have now a patch that fixes this.
|
| I'll post it when the compile finishes.
| IMHO if anything breaks by this, it is only an exposed bug that we hid
| earlier.
|
| I have not done extensive testing, but loading the UserGuide and
| cursoring throught it seems to work. I have not tested any real
| editing.
I just saw that there are problems with new documents, I'll look at
that shortly.
Here is the patch: (might not apply to a tree since I removed all ws
changes for Angus' benefit)
Please comment. (the patch is not very clean, but it moves uglyness
where it belongs.)
Index: src/lyxrow.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxrow.C,v
retrieving revision 1.18
diff -u -p -r1.18 lyxrow.C
--- src/lyxrow.C 11 Mar 2003 11:52:04 - 1.18
+++ src/lyxrow.C 13 Mar 2003 00:10:23 -
@@ -159,6 +159,9 @@ namespace {
bool nextRowIsAllInset(Row const & row, pos_type last)
{
+ if (last + 1 >= row.par()->size())
+ return false;
+
if (!row.par()->isInset(last + 1))
return false;
@@ -192,7 +195,7 @@ int Row::numberOfSeparators() const
pos_type p = max(pos(), par()->beginningOfBody());
int n = 0;
- for (; p <= last; ++p) {
+ for (; p < last; ++p) {
if (par()->isSeparator(p)) {
++n;
}
@@ -208,7 +211,7 @@ int Row::numberOfHfills() const
// hfill *DO* count at the beginning of paragraphs!
if (first) {
- while (first <= last && par()->isHfill(first)) {
+ while (first < last && par()->isHfill(first)) {
++first;
}
}
@@ -218,8 +221,8 @@ int Row::numberOfHfills() const
int n = 0;
// last, because the end is ignored!
- for (pos_type p = first; p <= last; ++p) {
+ for (pos_type p = first; p < last; ++p) {
if (par()->isHfill(p))
++n;
}
Index: src/paragraph_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/paragraph_pimpl.C,v
retrieving revision 1.53
diff -u -p -r1.53 paragraph_pimpl.C
--- src/paragraph_pimpl.C 12 Mar 2003 19:16:40 - 1.53
+++ src/paragraph_pimpl.C 13 Mar 2003 00:10:24 -
@@ -252,12 +252,14 @@ void Paragraph::Pimpl::rejectChange(pos_
Paragraph::value_type Paragraph::Pimpl::getChar(pos_type pos) const
{
- // This is in the critical path for loading!
- pos_type const siz = size();
- lyx::Assert(pos <= siz);
+ //lyx::Assert(pos <= siz);
// This is stronger, and I belive that this is the assertion
// that we should really use. (Lgb)
- //Assert(pos < size());
+ lyx::Assert(pos < size());
+
+#if 0
+ // This is in the critical path for loading!
+ pos_type const siz = size();
// Then this has no meaning. (Lgb)
if (!siz || pos == siz) {
@@ -266,7 +268,7 @@ Paragraph::value_type Paragraph::Pimpl::
<< " is a bit silly !" << endl;
return '\0';
}
-
+#endif
return text[pos];
}
Index: src/text.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text.C,v
retrieving revision 1.309
diff -u -p -r1.309 text.C
--- src/text.C 12 Mar 2003 23:19:09 - 1.309
+++ src/text.C 13 Mar 2003 00:10:26 -
@@ -422,10 +422,12 @@ bool LyXText::isBoundary(Buffer const *
int LyXText::leftMargin(BufferView * bview, Row const * row) const
{
Inset * ins;
- if ((row->par()->getChar(row->pos()) == Paragraph::META_INSET) &&
- (ins=row->par()->getInset(row->pos())) &&
- (ins->needFullRow() || ins->display()))
- return LEFT_MARGIN;
+
+ if (row->pos() < row->par()->size())
+ if ((row->par()->getChar(row->pos()) == Paragraph::META_INSET) &&
+ (ins = row->par()->getInset(row->pos())) &&
+ (ins->needFullRow() || ins->display()))
+ return LEFT_MARGIN;
LyXTextClass const & tclass =
bview->buffer()->params.getLyXTextClass();
@@ -615,10 +617,12 @@ int LyXText::leftMargin(BufferView * bvi
int LyXText::rightMargin(Buffer const & buf, Row const & row) const
{
Inset * ins;
- if ((row.par()->getChar(row.pos()) == Paragraph::META_INSET) &&
- (ins=row.par()->getInset(row.pos())) &&
- (ins->needFullRow() || ins->display()))
- return PAPER_MARGIN;
+
+ if (row.pos() < row.par()->size())
+ if ((row.par()->getChar(row.pos()) == Paragraph::META_INSET) &&
+ (ins=row.par()->getInset(row.pos())) &&
+ (ins->needFullRow() || ins->display()))
+ return PAPER_MARGIN;
LyXTextClass const & tclass = buf.params.getLyXTextClass();
LyXLayout_ptr const & layout = row.par()->layout();
@@ -722,7 +726,9 @@ LyXText::rowBreakPoint(BufferView & bv,
pos_type const body_pos = par->beginningOfBody();
pos_type const last = par->size();
pos_type point = last;
- pos_type i = pos;
+
+ if (pos == last)
+ return last;
// Now we iterate through until we reach the right margin
// or the end of the par, then choose the possible break
@@ -734,8 +740,9 @@ LyXText::rowBreakPoint(BufferView & bv,
// pixel width since last breakpoint
int chunkwidth = 0;
- for (i = pos; i < last;
Re: hanging lines in lyx-code
On 13 Mar 2003, Darren Freeman wrote: > Dear List, > > lyx1.3.1CVS, xforms-0.89 > > I think the behaviour of lyx-code with newlines is very irritating. > > For example, if I include a blank line on screen, it doesn't exist in > the output, which is opposite of what the user expects from lyx-code. > Instead I have to add *two* protected newlines, one to properly end the > line and another on the blank line to make it really appear. > > Middle-clicking data from other x-apps tends to lose newlines > altogether, but often keeps some newlines but not others. thus > reformatting is needed if you just pasted in a page of code and want it > to match the file on disc. > > Also it's quite easy to end up with a blank line trailing some lyx-code. > This line can't be deleted. You need to change its environment to > something else, like "Standard", and then it vanishes by itself. > Counterintuitive ;) > > Darren I agree, before Darren's post I have only been irritated, by empty lines _not_ vanishing in the Lyx code environment (interesting realization considering the DEPMs discussion) But now I tried inserting empty lines in the LyX code environment... well, I only tried for a few minutes, but I didn't even manage to get an empty line to appear on the output without putting something on it? (Which is strange... I thought it would?) Maybe someone who knows how this ought to behave shold check out 1.3.1? /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: [PATCH] InsetNewline
John Levon <[EMAIL PROTECTED]> writes: | On Wed, Mar 12, 2003 at 05:31:49PM +, John Levon wrote: | | > Forget it, I can't get the patch to work at all anyway, it segfaults | > looking for an inset at the end of a par that contains a newline. Lord | > knows why. | | Heh, good one META_INSET is now == 0. Guess what we return on a | bogus getChar(pos) ... | | We have bogus getChar()s in a number of places. I have now a patch that fixes this. I'll post it when the compile finishes. IMHO if anything breaks by this, it is only an exposed bug that we hid earlier. I have not done extensive testing, but loading the UserGuide and cursoring throught it seems to work. I have not tested any real editing. -- Lgb
Re: Feat. req: floating windows always on top
On Wed, 12 Mar 2003, Andre Poenitz wrote: > On Wed, Mar 12, 2003 at 04:27:15PM +0100, Helge Hafting wrote: > > >I find it annoying that the floating windows (such as Layout->Character > > >at the moment) are not always on top. That is, I select text, select > > >Layout->Character, do my stuff, then select more text. Now the floating > > >layout window is hidden since LyX is maximised to the full display size. > > > > My advice then is to not maximize the lyx window. > > The problem exists for certain focus policies, too. E.g. FocusFollowsMouse > and AutoRaise is currently unusable with the Qt frontend as the "floating" > windows do not appear below the mouse. I think this is something you should let your window-manager do for you... You set the window's attribute to "always on top", and if you don't want to do this manually every time, you configure your window manager to use "always on top" for all windows named "Character"? (Or belonging to class:class:etc...) Here I'm assuming that you can do this in your window manager of course... My point is that this isn't the task of Lyx. If your WM can't do this, maybe Qt has settings for keeping popups "always on top"? /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: Bug: Qt preferences dialog resize.
On Tue, Mar 11, 2003 at 09:03:37AM -0300, Joao Luis Meloni Assirati wrote: > This is a small bug. When resizing the Qt "Preferences" dialog, instead of > making wider the text boxes in the righ (what would be useful, for > example to enter large paths or commands with lots of options), it is the > tree of items in the left that becomes wider (what is not useful). Fixed. JMarc ? It's low risk john
Re: [PATCH] use ParagraphList iterator for reading the doc
On 13 Mar 2003, Lars Gullik Bjønnes wrote: > Christian Ridderström <[EMAIL PROTECTED]> writes: > > | > | Background and goal: > | I've got multiple accounts (several at work, at home and on a laptop), > | but I want to have a similar environment and similarly configured > | software on all the machines. So far I've been using scripts, CVS and > | manual merging... > > template files (similar to .in files in the autoconf world) and use > sed to create the real files... Thinking out loud: isn't that one way only? I think you mean that I have templates under version control, and then generate the configuration files? Unfortunately, programs love to modify the configuration files (including lyx nowadays :-), and I want to keep some of the changes, and propagate them to my other accounts. Hmm.. I guess that when it's time to see what has happened to my local config-file, I could first do the following. cvs update -p template > template.tmp sed --file=substitutions template.tmp > config.tmp Now I can compare: diff config.tmp config Then I (iteratively) modify 'template.tmp' until the result of sed --file=subsitutions template.tmp > config.tmp looks the way I like it, i.e. it keeps the changes I want. Now I can do mv template.tmp template cvs ci template to put the changes back into the repository. And then I have to repeat this on all machines. This would probably have been easier to explain as 'shooting' in terms of solving intial value problems. Mathematically, this is solving for 'template.tmp' in the "equation": Substitutions( template.tmp ) == config I was rather looking for something that solves it directly: template.tmp := SubstitutionsInverse(config) Preferably, 'cvs diff config' would be translated into: template := SubstitutionsInverse(config) cvs diff template and 'cvs up config' would translate into: cvs up template config := Substitutions(template) and so forth. Hmm, the operator 'sed --file=substitutions' maps to Substitions, and it's inverse could map to say 'sed --file=substitutionsInverse', then maybe I can do this with just templates and sed... making both the files "substitions" and "substitionsInverse" isn't that much work... Thanks Lars, I don't know if this is exactly what you meant, but it might be useful for me. /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: [maxb@ukf.net: Re: Addition for Cygwin]
On Thu, Mar 13, 2003 at 12:43:06AM +0100, Lars Gullik Bjønnes wrote: > "Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: > > | Here is one response from the bug-libtool people. Should I rework the Cygwin > | patch to just go to configure.in? > > Yes. Great. > Would it be possible to enclose this isn a CHECK_CYGWIN autoconf > function? Yes. I will give you a cywin-specific file to add to the config directory. -- 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)
Re: [maxb@ukf.net: Re: Addition for Cygwin]
"Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: | Here is one response from the bug-libtool people. Should I rework the Cygwin | patch to just go to configure.in? Yes. Would it be possible to enclose this isn a CHECK_CYGWIN autoconf function? -- Lgb
Re: [Patch] Fix and prettify Xforms Changes dialog.
On Tue, Mar 11, 2003 at 08:56:21AM +0900, Rob Lahaye wrote: > Actually, this problem occurs when two documents are in the buffer > and Changes-tracking is used. Somehow, the Changes features does not > work well when there's more than one document is in the buffer > (or another had been loaded prior to the current document!). Yes, well spotted. All should be OK now, hopefully. john
Re: The DEPM discussion
On Wed, Mar 12, 2003 at 08:48:31PM +0100, Alfredo Braunstein wrote: > Dunno, nobody answered to the poll, and I probably lack the lyx knowledge to > make my patch to work flawlessly (or even know how much work is needed). Probably not much at all. > Maybe it's not the right time. It's the right time: let's come to some rough consensus and apply patches. john
[maxb@ukf.net: Re: Addition for Cygwin]
Here is one response from the bug-libtool people. Should I rework the Cygwin patch to just go to configure.in? - Forwarded message from Max Bowsher <[EMAIL PROTECTED]> - From: "Max Bowsher" <[EMAIL PROTECTED]> To: "Kayvan A. Sylvan" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> Subject: Re: Addition for Cygwin Date: Wed, 12 Mar 2003 23:05:43 - Kayvan A. Sylvan wrote: >> Hello libtool maintainers, >> >> I am one of the people working on the LyX project. In order to get >> LyX >> to compile with the latest Cygwin, I had to make the following patch >> to libtool.m4. >> >> I am wondering if anything like this is in the upcoming >> autoconf/automake/libtool tool chain already. Is this something that >> should be done? No. Not all projects want these settings. The proper place for this in the configure.in of individual projects (see glib/gtk+ for an example use of conditional -mms-bitfields/-fnative-struct). Max. - End forwarded message - -- 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)
Re: The DEPM discussion
On Wed, Mar 12, 2003 at 11:24:10PM +, Angus Leeming wrote: > >> Would it be possible to have the collapsing of empty paragraphs take > >> place when the user presses a newline anywhere else in the document? > > > > This way the document jumps about oddly. > > > Look at the complaints we had about the graphics loading. > > Which lead Alfredo to devise an elegant solution, keeping the topmost > visible row steady. Would it not be possible to extend that to keeping the > row with the cursor in it (if visible) steady? Possibly but then we're not far away from being back in DEPM land anyway in terms of complexity (since you have to keep the cursor row stable). I wonder if I get get some more support for my favoured solution if I implemented more bits of paragraph-pruning. john
Re: The DEPM discussion
John Levon wrote: > On Wed, Mar 12, 2003 at 11:51:34PM +0200, Martin Vermeer wrote: > >> Would it be possible to have the collapsing of empty paragraphs take >> place when the user presses a newline anywhere else in the document? > > This way the document jumps about oddly. > Look at the complaints we had about the graphics loading. Which lead Alfredo to devise an elegant solution, keeping the topmost visible row steady. Would it not be possible to extend that to keeping the row with the cursor in it (if visible) steady? Just a thought on you objection... -- Angus
ParagraphParameters' operator=()
The Paragraph controller currently contains the following code.
void ControlParagraph::setParams()
{
if (!pp_.get())
pp_.reset(new ParagraphParameters());
/// get paragraph
Paragraph const * par_ = bufferview()->getLyXText()->cursor.par();
/// Set the paragraph parameters
*pp_ = par_->params();
/// this needs to be done separately
pp_->labelWidthString(par_->getLabelWidthString());
/// alignment
LyXLayout_ptr const & layout = par_->layout();
if (pp_->align() == LYX_ALIGN_LAYOUT)
pp_->align(layout->align);
Where pp_ is of type boost::scoped_ptr. I'm confused by
the code above.
*pp_ = par_->params();
is using the implicit operator=() of the ParagraphParameters struct, but the
next line suggests that this implicit operator doesn't cut the mustard.
Looking at ParagraphParameters I see it contains data:
boost::shared_ptr param;
so the implicit operator=() should be fine. Nonetheless, the code above
exists for a reason. Can someone advise why labelWidthString and align have
to be set separately? Looking further I see stuff like
void ParagraphParameters::spaceTop(VSpace const & vs)
{
ParameterStruct tmp(*param);
tmp.added_space_top = vs;
set_from_struct(tmp);
}
which looks really messy (ie, confuses me further).
Should I write an operator=()? What's the best way to proceed?
--
Angus
Re: Control-Enter in a My-Address environment is hosed
On Wed, Mar 12, 2003 at 10:51:08PM +, Angus Leeming wrote: > John? That's intriguing isn't it ! Luckily, it's a last-minute silly, I think. Hold on john
Re: The DEPM discussion
On Wed, Mar 12, 2003 at 11:51:34PM +0200, Martin Vermeer wrote: > Would it be possible to have the collapsing of empty paragraphs take > place when the user presses a newline anywhere else in the document? This way the document jumps about oddly. Look at the complaints we had about the graphics loading. john
Re: [PATCH] use ParagraphList iterator for reading the doc
Christian Ridderström <[EMAIL PROTECTED]> writes: | | Background and goal: | I've got multiple accounts (several at work, at home and on a laptop), | but I want to have a similar environment and similarly configured | software on all the machines. So far I've been using scripts, CVS and | manual merging... template files (similar to .in files in the autoconf world) and use sed to create the real files... -- Lgb
Control-Enter in a My-Address environment is hosed
John? -- Angus
Re: [PATCH] use ParagraphList iterator for reading the doc
On Wed, 12 Mar 2003, Kuba Ober wrote: > No sarcasm intended, but I'd drop CVS and switch to Aegis. I'm using Aegis and > it does exactly what you're looking for. No need to write scripts to do > simple things like that. > Sorry for going off topic here... but does anyone have a tool that solves this problem: Background and goal: I've got multiple accounts (several at work, at home and on a laptop), but I want to have a similar environment and similarly configured software on all the machines. So far I've been using scripts, CVS and manual merging... Problem: Some files, typically configuration files, are slightly different on different machines. Mostly it's file paths, referring to for instance: ~/.something/aFile The problem is that '~' is different on the different accounts... and the configuration files don't understand '~' or '$HOME' (LyX doesn't understand this either, but I'm going to fix that someday). Solution: Basically I'd like a system that can do subsitutions transparently when accessing the repository. Here's an example of an imaginary config-file on one machine: set someOptionsFile = /home/chr/.pgm/options and here's the corresponding file on another machine: set someOptionsFiel = /afs/md.kth.se/md/home/chr/.pgm/options Even though they textually are different, they both correspond to: set someOptionssFile = $HOME/.pgm/options so I'd like the software to handle this. (I wouldof course have to let it know what and how to substitute stuff etc.) This doesn't strike me as that difficult.. it ought to just require a wrapper, but I haven't had time to write it... (Then I'd also like the system to handle soft links in a similar manner, but that's another story..) Does any of this ring a bell for someone? > PS. Okay, that's wishful thinking, because for whatever reason the developer > communities prefer to suffer with CVS rather than moving to something better > :( People shrug at Aegis and keep using CVS, which they complain about. I use > Aegis and live a better life. Your choice ;-))) I looked at it briefly just now, but I couldn't use it for my work since I have to do some stuff locally on windows (yes... I tried using a Samba server, but then the make system recompiled everything everytime... ) So, regardless of Aegis (potential) superiority, I'm stuck with CVS. PS. Feel free to throw stuff at me for going so off-topic here... guess TV sucks right now :) I might as well go completely overboard and describe a neat idea for a scam I just saw. Imagine that you recieve an anonymous tip successfully predicting who is going to win a sports game (say baseball). Then, the next week you recieve another tip.. also successfull. And the next week again.. again .. and again. You have now gotten this anonymous tip five weeks in a row, the sixth letter has a surprise for you. It says that the first five tips were free, but for this tip you have to pay (250 EUR)... What's going on here? How could he send you five successful predictions in a row? Should you pay the money and go to a bookie and make a bet? DS -- Christian Ridderström http://www.md.kth.se/~chr
Re: Cygwin build patch - impgen.c fix
On Tue, Mar 11, 2003 at 03:47:47PM +0100, Lars Gullik Bjønnes wrote:
> "Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes:
>
> | This makes it possible to build lyx on Cygwin with GCC 3.2 (instead
> | of requiring that lyx be built with GCC2).
> |
> | Please apply.
>
> Note that libtool.m4 is not our file. It is from the libtool package.
> And that is where this patch should really go.
>
> Have any of this been sent to the libtool people?
Today, I sent the patch off to the libtool people.
Regardless, I think it should be applied to our own version of the file.
At some future date, that version will get supplanted by the latest
and greatest from libtool (which should hopefully contain the patch
or some variant).
In addition, the following patch fixes a problem that is introduced
only in the LyX-specific version of the libtool.m4. There are suprious
tab characters where spaces should be. This matters because the
generated "impgen.c" file, used at the linking stage on Cygwin, will
not compile (needing to be hand-massaged).
With these patches, LyX on Cygwin now compiles cleanly with the latest
Cygwin (GCC-3, XFree86, tetex), requiring no special hacks!
---Kayvan
--
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)
Index: config/libtool.m4
===
RCS file: /cvs/lyx/lyx-devel/config/libtool.m4,v
retrieving revision 1.5
diff -u -r1.5 libtool.m4
--- config/libtool.m4 2002/08/14 11:24:22 1.5
+++ config/libtool.m4 2003/03/12 21:34:49
@@ -2737,44 +2775,44 @@
#
# dll = open(filename, O_RDONLY|O_BINARY);
# if (dll < 1)
-# return 1;
+# return 1;
#
# dll_name = filename;
#
# for (i=0; filename[i]; i++)
-# if (filename[i] == '/' || filename[i] == '\\' || filename[i] == ':')
-# dll_name = filename + i +1;
+# if (filename[i] == '/' || filename[i] == '\\' || filename[i] == ':')
+# dll_name = filename + i +1;
#
# pe_header_offset = pe_get32 (dll, 0x3c);
# opthdr_ofs = pe_header_offset + 4 + 20;
# num_entries = pe_get32 (dll, opthdr_ofs + 92);
#
# if (num_entries < 1) /* no exports */
-# return 1;
+# return 1;
#
# export_rva = pe_get32 (dll, opthdr_ofs + 96);
# export_size = pe_get32 (dll, opthdr_ofs + 100);
# nsections = pe_get16 (dll, pe_header_offset + 4 +2);
# secptr = (pe_header_offset + 4 + 20 +
-#pe_get16 (dll, pe_header_offset + 4 + 16));
+# pe_get16 (dll, pe_header_offset + 4 + 16));
#
# expptr = 0;
# for (i = 0; i < nsections; i++)
# {
-# char sname[8];
-# unsigned long secptr1 = secptr + 40 * i;
-# unsigned long vaddr = pe_get32 (dll, secptr1 + 12);
-# unsigned long vsize = pe_get32 (dll, secptr1 + 16);
-# unsigned long fptr = pe_get32 (dll, secptr1 + 20);
-# lseek(dll, secptr1, SEEK_SET);
-# read(dll, sname, 8);
-# if (vaddr <= export_rva && vaddr+vsize > export_rva)
-# {
-# expptr = fptr + (export_rva - vaddr);
-# if (export_rva + export_size > vaddr + vsize)
-# export_size = vsize - (export_rva - vaddr);
-# break;
-# }
+# char sname[8];
+# unsigned long secptr1 = secptr + 40 * i;
+# unsigned long vaddr = pe_get32 (dll, secptr1 + 12);
+# unsigned long vsize = pe_get32 (dll, secptr1 + 16);
+# unsigned long fptr = pe_get32 (dll, secptr1 + 20);
+# lseek(dll, secptr1, SEEK_SET);
+# read(dll, sname, 8);
+# if (vaddr <= export_rva && vaddr+vsize > export_rva)
+# {
+# expptr = fptr + (export_rva - vaddr);
+# if (export_rva + export_size > vaddr + vsize)
+# export_size = vsize - (export_rva - vaddr);
+# break;
+# }
# }
#
# expdata = (unsigned char*)malloc(export_size);
@@ -2788,8 +2826,8 @@
# printf ("EXPORTS\n");
# for (i = 0; i
Re: The DEPM discussion
Martin Vermeer wrote: > Would it be possible to have the collapsing of empty paragraphs take > place when the user presses a newline anywhere else in the document? > Then you can freely move the cursor about to fetch a piece to insert, > but there will never be more than one "hole" waiting for the insert. > > Solves the const-ness problem and still provides intuitive feedback to > the effect of "never having more than one hole pending". Do I miss > something? Interesting option. I could even like it. Alfredo
Re: [PATCH] InsetNewline
John Levon wrote: > We have bogus getChar()s in a number of places. Can we at least start > making some console noise for them ? Ho no. Could it be that you have found the root of the existance of the little square? Damn! Alfredo
Re: File loading error.
Dekel Tsur <[EMAIL PROTECTED]> writes: | On Wed, Mar 12, 2003 at 09:41:00PM +0100, Lars Gullik Bj?nnes wrote: | > | > The why is my Userguide loading? | > | > (older format I guess) | > | | > | Yes, lyx2lyx will be ok ... | > | | > | > And at least temporary you need to handle this with some backwards | > | > compability stuff. | > | | > | Hmm OK. | > | | > | I don't know how though, how do we detect the end of the header ? | > Easier solution is perhaps to up the format. | | This means that lyx2lyx will be broken into a lot of modules, and it might | make it harder to maintain. Only temprary... the format versions that _only_ exists during the dev cycle should not be supported by lyx2lyx later, so then those modules can be collapsed into a single one. -- Lgb
Re: The DEPM discussion
Christian Ridderström wrote: > Here's a new idea (dare I say "novel" ;-) > > Give empty paragraphs (and empty double spaces) a visual marker, for > instance a different background colour? Flashing background? Animations of > a black hole? Ok... maybe just a different background, light gray? > > This visual marker informs the user that the space will not appear in > the output. "Purging" the DEPMs could even be optional at save. £$%£&! >From my original post on the subject: |Proposal 1) Plain forbid 3 spaces / 2 empty paragraphs (in order to |discourage space/newline formatting abuse, do not load nor save double |spaces, empty paragraphs). | |Proposal 2) Mark double/triple/... spaces and empty pars with some |disgusting mark or colour, to encourage their removal. Can be combined with |1) John even criticized it, and I agree with him. Alfredo
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
Dekel Tsur <[EMAIL PROTECTED]> writes: | On Wed, Mar 12, 2003 at 07:23:10PM +0100, Lars Gullik Bj?nnes wrote: | > Kuba Ober <[EMAIL PROTECTED]> writes: | > | > I'll have a look at aegis. | > | > At first glance it seems to be similar to BitKeeper? What are the | > differences? (And why doesn't Linus want to use aegis?) | > | > I'll go through the documentation. | | Another alternative is Subversion. I would at least wait for version 1.0. -- Lgb
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
Dekel Tsur <[EMAIL PROTECTED]> writes: | On Wed, Mar 12, 2003 at 07:23:10PM +0100, Lars Gullik Bj?nnes wrote: | > Kuba Ober <[EMAIL PROTECTED]> writes: | > | > I'll have a look at aegis. | > | > At first glance it seems to be similar to BitKeeper? What are the | > differences? (And why doesn't Linus want to use aegis?) | > | > I'll go through the documentation. | | Another alternative is Subversion. Which is even more unfinished. -- Lgb
Re: File loading error.
On Wed, Mar 12, 2003 at 09:41:00PM +0100, Lars Gullik Bj?nnes wrote: > | > The why is my Userguide loading? > | > (older format I guess) > | > | Yes, lyx2lyx will be ok ... > | > | > And at least temporary you need to handle this with some backwards > | > compability stuff. > | > | Hmm OK. > | > | I don't know how though, how do we detect the end of the header ? > Easier solution is perhaps to up the format. This means that lyx2lyx will be broken into a lot of modules, and it might make it harder to maintain. A possible solution: change the code in readFile() to run 'lyx2lyx -f (LYX_FORMAT-1) filename' on files for which file_format == LYX_FORMAT, and disable this code when you think all user have updated their file (it is possible to keep it enabled and disable it only before a new release).
Re: The DEPM discussion
On Wed, Mar 12, 2003 at 04:51:22PM +, John Levon spake thusly: > > Here's a paragraph. Here's a CoMPLICAted-MarkUP-PHRASE. > Blah blah blah blah > | > Blah blah blah blah x 1000 > > Now move the cursor up to select the complicated markup for copying and > you have to introduce a newline again. > > It's even worse when you have cursor-follows-scrollbar and you go to > check something a few pages up Would it be possible to have the collapsing of empty paragraphs take place when the user presses a newline anywhere else in the document? Then you can freely move the cursor about to fetch a piece to insert, but there will never be more than one "hole" waiting for the insert. Solves the const-ness problem and still provides intuitive feedback to the effect of "never having more than one hole pending". Do I miss something? Martin pgp0.pgp Description: PGP signature
Re: The DEPM discussion
On Wed, 12 Mar 2003, Alfredo Braunstein wrote: > The patch was good only to show what it feels like anyway. I don't know how > hard would it be to solve all little (?) arising problems. John's patch > seems to be in a quasi-working state. Here's a new idea (dare I say "novel" ;-) Give empty paragraphs (and empty double spaces) a visual marker, for instance a different background colour? Flashing background? Animations of a black hole? Ok... maybe just a different background, light gray? This visual marker informs the user that the space will not appear in the output. "Purging" the DEPMs could even be optional at save. But I'm guessing that I'd like a keyboard shortcut for purging... I'd probably want to purge the document regularly... Btw, I'm still rooting for the horizontal cursor :-) /C -- Christian Ridderström http://www.md.kth.se/~chr
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On Wed, Mar 12, 2003 at 07:23:10PM +0100, Lars Gullik Bj?nnes wrote: > Kuba Ober <[EMAIL PROTECTED]> writes: > > I'll have a look at aegis. > > At first glance it seems to be similar to BitKeeper? What are the > differences? (And why doesn't Linus want to use aegis?) > > I'll go through the documentation. Another alternative is Subversion.
Re: The DEPM discussion
On 12 Mar 2003, Jean-Marc Lasgouttes wrote: > > "John" == John Levon <[EMAIL PROTECTED]> writes: > > John> Maybe. But it is new and quite unexpected. It *does* feel > John> reasonably natural, but I am still worried. > > I have not tested it, so I cannot really comment. > Here's just a thought Alfredo how difficult would it be to backport the cursor patch for 1.3.1cvs? (I'm not talking about introducing it into 1.3.1cvs... just about making a special version that I can test) I'd like to work using the cursor thing over an extended period of time, but since I'm finishing up my thesis now I don't want to use 1.4.0cvs... and the file formats doesn't seem to completely compatible... /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: Edit->Tabular greyed out
Garst R. Reese wrote: > Last night's CVS > xforms-1.0 > > Garst Works for me when I place the cursor inside the tabuular. -- Angus
Re: The DEPM discussion
On Wed, Mar 12, 2003 at 09:45:29PM +0100, Christian Ridderstr?m wrote: > My brain seem to work so that I first think about _where_ I'm going to > add text, and then I go there and create some space, then I go and get > whatever it is... does this seem familiar to any of you? > > > That's the big point indeed. The horizontal cursor did that didn't it? > > I agree with that... and I wonder how my behaviour that I described above > would change using it? It would break regards john
Re: The DEPM discussion
On 12 Mar 2003, Jean-Marc Lasgouttes wrote: > > "John" == John Levon <[EMAIL PROTECTED]> writes: > > > John> 2) not annoy the user with vanishing paragraphs > > Are you sure this is _so_ annoying? I tend to like this behaviour I usually like it to, but sometimes it _is_ annoying, namely in this situation: I'm going to create a new paragraph based on some other text, then I typically first go to where I want to create the paragraph and press enter... Then I move the cursor to wherever I'm going to copy the text from - and my newly created paragraph vanishes... this can be really annoying even though I ought to know how this works after 5 years.. My brain seem to work so that I first think about _where_ I'm going to add text, and then I go there and create some space, then I go and get whatever it is... does this seem familiar to any of you? > John> 4) encourage the user to understand that spacing is not created > John> by pressing return > > That's the big point indeed. The horizontal cursor did that didn't it? I agree with that... and I wonder how my behaviour that I described above would change using it? /C -- Christian Ridderström http://www.md.kth.se/~chr
Re: File loading error.
On Wed, Mar 12, 2003 at 09:41:00PM +0100, Lars Gullik Bj?nnes wrote: > Ever wondered why the compability code was so hard to get right? > > Easier solution is perhaps to up the format. And the easiest and sanest solution is to get the 3 people who have documents from 1.4.0cvs to add \end_header to their files... john
Re: File loading error.
John Levon <[EMAIL PROTECTED]> writes: | On Wed, Mar 12, 2003 at 09:25:14PM +0100, Lars Gullik Bj?nnes wrote: | | > The why is my Userguide loading? | > (older format I guess) | | Yes, lyx2lyx will be ok ... | | > And at least temporary you need to handle this with some backwards | > compability stuff. | | Hmm OK. | | I don't know how though, how do we detect the end of the header ? Ever wondered why the compability code was so hard to get right? Easier solution is perhaps to up the format. -- Lgb
Re: File loading error.
On Wed, Mar 12, 2003 at 09:25:14PM +0100, Lars Gullik Bj?nnes wrote: > The why is my Userguide loading? > (older format I guess) Yes, lyx2lyx will be ok ... > And at least temporary you need to handle this with some backwards > compability stuff. Hmm OK. I don't know how though, how do we detect the end of the header ? john
Re: File loading error.
John Levon <[EMAIL PROTECTED]> writes: | On Wed, Mar 12, 2003 at 09:13:56PM +0100, Lars Gullik Bj?nnes wrote: | | > The error: | > "Textclass error | > Document uses an unknown textclass 'Standard'.-- substituting" | > | > Can this be the last paragraph changes? | | Add "\end_header" to the end of the header. I didn't bother bumping the | format because we already bumped it for the change tracking stuff. The why is my Userguide loading? (older format I guess) And at least temporary you need to handle this with some backwards compability stuff. -- Lgb
Re: File loading error.
On Wed, Mar 12, 2003 at 09:13:56PM +0100, Lars Gullik Bj?nnes wrote: > The error: > "Textclass error > Document uses an unknown textclass 'Standard'.-- substituting" > > Can this be the last paragraph changes? Add "\end_header" to the end of the header. I didn't bother bumping the format because we already bumped it for the change tracking stuff. john
File loading error.
The error: "Textclass error Document uses an unknown textclass 'Standard'.-- substituting" Can this be the last paragraph changes? With this document: newfile1.lyx Description: Binary data -- Lgb
Re: The DEPM discussion
John Levon wrote: > On Wed, Mar 12, 2003 at 06:29:54PM +0100, Alfredo Braunstein wrote: >> John, is it too hard to forbid them consistently? > Isn't that DEPM ? Not exactly, because the empty line cleanup can be done at edit time, not at cursor moving time. But I agree that we have some DEPM nightmare coming back (that would _not_ be avoided even with the h.cursor way). One more thing with your patch, it seems that DESM is not working completely ok, I can generate a space at the start of a paragraph. Apart that (and the par delete problem of the other post) it seems to work as intended. > OK theoretically we can suck in the remaining cases where we can have > > 1 empty paragraph in a row. But I'm not going to put the effort in at > the moment since it seems things are swinging your way. Dunno, nobody answered to the poll, and I probably lack the lyx knowledge to make my patch to work flawlessly (or even know how much work is needed). Maybe it's not the right time. Regards, Alfredo
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On Wed, Mar 12, 2003 at 02:13:16PM -0500, Kuba Ober wrote: > Probably because Aegis, although a very cleanly and understanably coded > project, is essentially one man's work for most part. If something happens to It's more likely that it can't handle what he needs. at least your description of how things work put me right off it (that is, I couldn't follow it within 10 seconds or so of reading it). What're all these obscure edit and send commands etc. ? We just don't need administration overheads. All I want is properly distributed repos, it's that simple :) john
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On środa 12 marzec 2003 01:23 pm, Lars Gullik Bjønnes wrote: > Kuba Ober <[EMAIL PROTECTED]> writes: > > I'll have a look at aegis. > > At first glance it seems to be similar to BitKeeper? What are the > differences? (And why doesn't Linus want to use aegis?) > > I'll go through the documentation. Probably because Aegis, although a very cleanly and understanably coded project, is essentially one man's work for most part. If something happens to Peter Miller ( forbid), Aegis becomes (at least for a while) a project without maintainer, and without architect's support. I guess Linus had to use something that has strong commercial backing, and I understand that decision. And, because Bitkeeper has a company behind it (rather than a single person in case of Aegis), the requests for improvements and fixes can be integrated quicker. Although Aegis is open source and GPL, it's still currently being developed mainly by one person. One of the reasons why it may be unpopular is that Peter hates recursive make :), and rightly so. He wrote a very educational article why recursive make is harmful. I hate recursive make too, so I don't use it :). I guess that it's hard for people who are used to autotools and recursive makefiles the autotools generate to understand that there are better things to do with life than hunting brokenness which is handled all right by simpler and more powerful tools (as in automake+gmake replaced by cook). My guesstimate is that projects of LyX's size and developer diversity, if moved from CVS and automake (let's leave autoconf in for the time being, it's needed for some stuff) over to Aegis and Cook, can save about 5% of recurring developer time, after a short "adjustment" period of a 2-3 months, when productivity might suffer while people get used to better tools and forget limitations of the previous tools ;-). Personally, I'm lucky not to need autoconf for my projects (I build on latest RedHat and on Windows only), so I'm just using cook and Aegis, and it works fine for both linux and windows builds. Windows builds need some wine trickery, but once you do it and put into scripts, with Aegis multiplatform support it becomes a breeze. Aegis will even tell you that say an integration build succeeded on Linux/GCC platform but failed on Windows platform, and then you're back to workarounds for your not-so-favourite Windows compiler :). Oh, I use BCC55, so I'm not complaining too much -- it was much worse with VC6. Cheers, Kuba Ober
Re: [PATCH] GCC 3.3 warnings.
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
|
| > This patch fixes some GCC 3.3 warnings. If this is the best way to
| > do it can be argued.
| >
| > Comments?
|
| -theCatcode['&'] = catAlign;
| +theCatcode[static_cast('\\')] = catEscape;
|
| Why not:
|
| setCatcode('&', catAlign);
I have no idea, not my code. I only wanted the warnings gone.
| void setCatcode(char c, CATCODETYPE val) {
| theCatcode[static_cast(c)] = val;
| }
|
| Saves polluting the source with loads of static_casts.
Sure, I'd be happy with that solution as well.
--
Lgb
Re: [PATCH] GCC 3.3 warnings.
Angus Leeming <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: | | > This patch fixes some GCC 3.3 warnings. If this is the best way to | > do it can be argued. | > | > Comments? | | Why not do it properly and make papersize2 of type vector::size_type? | In fact, don't we have a lyx::index_type that could fit here? | | I've looked through a whole heap of lines to find 4 static casts in | lyx-proper and a stack of 'em in tex2lyx because André has used '\\' | as an index entry. The rest is just whitespace. If you seriously want | comments you should strip out the noise. I stripped out all noise from other files. -- Lgb
Re: Patch: inverse search.
Kuba Ober <[EMAIL PROTECTED]> writes: | > | Doesn't Kuba mean | > | | > | /tmp/lyx --- owned by you | > | > The problem is then to make this happen. | > | > So the top dir would have to be /tmp/lyx- that you | > can lookup somewhere else, f.ex. in ~/.lyx/pipeinfo | | Like DCOP does ;-) Yes, I thought that a nice idea. -- Lgb
Re: [PATCH] GCC 3.3 warnings.
Lars Gullik Bjønnes wrote:
> This patch fixes some GCC 3.3 warnings. If this is the best way to
> do it can be argued.
>
> Comments?
-theCatcode['&'] = catAlign;
+theCatcode[static_cast('\\')] = catEscape;
Why not:
setCatcode('&', catAlign);
void setCatcode(char c, CATCODETYPE val) {
theCatcode[static_cast(c)] = val;
}
Saves polluting the source with loads of static_casts.
--
Angus
Re: Patch: inverse search.
On środa 12 marzec 2003 01:27 pm, Lars Gullik Bjønnes wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > | Alfredo Braunstein wrote: > | > Kuba Ober wrote: > | >> There's no reason for a globally fixed filename. At least, the file > | >> name containing the user name or uid. That's what DCOP does in KDE. > | > > | > The file name containing only the user name or uid doesn't forbid > | > another user to take it first. > | > > | > If DCOP allows another user to forbid me from running it then I > | > think that I'm on the safe side by saying that it's broken. > | > > | > Alfredo > | > | Doesn't Kuba mean > | > | /tmp/lyx --- owned by you > > The problem is then to make this happen. > > So the top dir would have to be /tmp/lyx- that you > can lookup somewhere else, f.ex. in ~/.lyx/pipeinfo Like DCOP does ;-) Cheers, Kuba Ober
Re: [PATCH] GCC 3.3 warnings.
Lars Gullik Bjønnes wrote: > This patch fixes some GCC 3.3 warnings. If this is the best way to > do it can be argued. > > Comments? Why not do it properly and make papersize2 of type vector::size_type? In fact, don't we have a lyx::index_type that could fit here? I've looked through a whole heap of lines to find 4 static casts in lyx-proper and a stack of 'em in tex2lyx because André has used '\\' as an index entry. The rest is just whitespace. If you seriously want comments you should strip out the noise. -- Angus
Re: Another lyx2lyx problem
On Wed, Mar 12, 2003 at 03:33:04PM +0100, Jean-Marc Lasgouttes wrote: > > Actually, the latest changes to lyx2lyx are not enough to be able to > update revtex4.cls. > > The attached diff shows 2 problems: > > 1/ in the old Info inset, the beginning of the message is on the same > line as \begin_inset. It is lost when using lyx2lyx I fixed that, although files creates with LyX 1.1.6 do not contain text in the '\begin_inset Info' line. > 2/ there is an ERT inset in there, and it gets lost in the conversion > (where I use -f 218). I understand that the file is not really 218 nor > 221, but is this unavoidable? I'm not going to fix that.
Re: Another lyx2lyx problem
On Wed, Mar 12, 2003 at 03:12:26PM +0100, Jean-Marc Lasgouttes wrote: > > And I cannot make -o work (although the code for it seems resonable). It works for me. Note that the -o should appear before the filename.
Re: Another lyx2lyx problem
On Wed, Mar 12, 2003 at 03:07:59PM +0100, Jean-Marc Lasgouttes wrote: > > If I try to convert revtex4.lyx with latest lyx2lyx to fix it using > lyx2lyx/lyx2lyx -f 218 templates/revtex4.lyx > I see the warning: > Proposed and input file formats do not match: 218 221 > > This is good, except that this warning is sent to stdout instead of > stderr, so that if I redirect the output, it will go i nthe file > itself. > > I do not know whether there are other warnings/errors which suffer > from this. Fixed.
[PATCH] GCC 3.3 warnings.
This patch fixes some GCC 3.3 warnings. If this is the best way to do
it can be argued.
Comments?
Index: src/bufferparams.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/bufferparams.C,v
retrieving revision 1.48
diff -u -p -r1.48 bufferparams.C
--- src/bufferparams.C 12 Mar 2003 11:52:22 - 1.48
+++ src/bufferparams.C 12 Mar 2003 18:10:34 -
@@ -364,8 +364,8 @@ void BufferParams::writeFile(ostream & o
spacing.writeFile(os);
- os << "\\papersize " << string_papersize[papersize2]
- << "\n\\paperpackage " << string_paperpackages[paperpackage]
+ os << "\\papersize " << string_papersize[static_cast(papersize2)]
+ << "\n\\paperpackage " << string_paperpackages[static_cast(paperpackage)]
<< "\n\\use_geometry " << use_geometry
<< "\n\\use_amsmath " << use_amsmath
<< "\n\\use_natbib " << use_natbib
Index: src/mathed/math_parser.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_parser.C,v
retrieving revision 1.269
diff -u -p -r1.269 math_parser.C
--- src/mathed/math_parser.C 4 Mar 2003 09:06:13 - 1.269
+++ src/mathed/math_parser.C 12 Mar 2003 18:10:35 -
@@ -152,21 +152,21 @@ void catInit()
fill(theCatcode + 'a', theCatcode + 'z' + 1, catLetter);
fill(theCatcode + 'A', theCatcode + 'Z' + 1, catLetter);
- theCatcode['\\'] = catEscape;
- theCatcode['{'] = catBegin;
- theCatcode['}'] = catEnd;
- theCatcode['$'] = catMath;
- theCatcode['&'] = catAlign;
- theCatcode['\n'] = catNewline;
- theCatcode['#'] = catParameter;
- theCatcode['^'] = catSuper;
- theCatcode['_'] = catSub;
- theCatcode[''] = catIgnore;
- theCatcode[' '] = catSpace;
- theCatcode['\t'] = catSpace;
- theCatcode['\r'] = catNewline;
- theCatcode['~'] = catActive;
- theCatcode['%'] = catComment;
+ theCatcode[static_cast('\\')] = catEscape;
+ theCatcode[static_cast('{')] = catBegin;
+ theCatcode[static_cast('}')] = catEnd;
+ theCatcode[static_cast('$')] = catMath;
+ theCatcode[static_cast('&')] = catAlign;
+ theCatcode[static_cast('\n')] = catNewline;
+ theCatcode[static_cast('#')] = catParameter;
+ theCatcode[static_cast('^')] = catSuper;
+ theCatcode[static_cast('_')] = catSub;
+ theCatcode[static_cast('')] = catIgnore;
+ theCatcode[static_cast(' ')] = catSpace;
+ theCatcode[static_cast('\t')] = catSpace;
+ theCatcode[static_cast('\r')] = catNewline;
+ theCatcode[static_cast('~')] = catActive;
+ theCatcode[static_cast('%')] = catComment;
}
@@ -967,7 +967,7 @@ void Parser::parse1(MathGridInset & grid
parse(cell->back().nucleus()->cell(0), FLAG_ITEM, mode);
}
- else if (t.cs() == "ref" || t.cs() == "prettyref" ||
+ else if (t.cs() == "ref" || t.cs() == "prettyref" ||
t.cs() == "pageref" || t.cs() == "vpageref" || t.cs() == "vref") {
cell->push_back(MathAtom(new RefInset(t.cs(;
parse(cell->back().nucleus()->cell(1), FLAG_OPTION, mode);
Index: src/tex2lyx/tex2lyx.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/tex2lyx/tex2lyx.C,v
retrieving revision 1.27
diff -u -p -r1.27 tex2lyx.C
--- src/tex2lyx/tex2lyx.C 6 Mar 2003 10:39:54 - 1.27
+++ src/tex2lyx/tex2lyx.C 12 Mar 2003 18:10:36 -
@@ -46,19 +46,20 @@ void parse(Parser & p, ostream & os, uns
char const OPEN = '<';
char const CLOSE = '>';
-// rather brutish way to code table structure in a string:
-//
-// \begin{tabular}{ccc}
-//1 & 2 & 3\\ \hline
-//\multicolumn{2}{c}{4} & 5\\
-//6 & 7 \\
-// \end{tabular}
-//
-// gets "translated" to:
-//
-// 1 TAB 2 TAB 3 LINE
-// HLINE 2 MULT c MULT 4 TAB 5 LINE
-// 5 TAB 7 LINE
+/* rather brutish way to code table structure in a string:
+
+ \begin{tabular}{ccc}
+1 & 2 & 3\\ \hline
+\multicolumn{2}{c}{4} & 5\\
+6 & 7 \\
+ \end{tabular}
+
+ gets "translated" to:
+
+ 1 TAB 2 TAB 3 LINE
+ HLINE 2 MULT c MULT 4 TAB 5 LINE
+ 5 TAB 7 LINE
+*/
char const TAB = '\001';
char const LINE = '\002';
@@ -158,7 +159,7 @@ string const trim(string const & a, char
void split(string const & s, vector & result, char delim = ',')
{
- istringstream is(s);
+ istringstream is(s);
string t;
while (getline(is, t, delim))
result.push_back(t);
@@ -174,7 +175,7 @@ map split_map(string con
for (size_t i = 0; i < v.size(); ++i) {
size_t const pos = v[i].find('=');
string const index = v[i].substr(0, pos);
- string const value = v[i].substr(pos + 1, string::npos);
+ string const value = v[i].substr(pos + 1, string::npos);
res[trim(index)] = trim(value);
}
return res;
@@ -186,8 +187,8 @@ string join(vector const & input
ostringstream os;
for (size_t i = 0; i != input.size(); ++i) {
if (i)
- os << delim;
- os << input[i];
+ os << delim;
+ os << input[i];
}
return os.str();
}
@@ -266,7 +267,7 @@ void handle_par(ostream & os)
return;
os << "\n\\layout ";
string s = curr_env();
-
Re: Patch: inverse search.
Angus Leeming <[EMAIL PROTECTED]> writes: | Alfredo Braunstein wrote: | | > Kuba Ober wrote: | > | >> There's no reason for a globally fixed filename. At least, the file | >> name containing the user name or uid. That's what DCOP does in KDE. | > | > The file name containing only the user name or uid doesn't forbid | > another user to take it first. | > | > If DCOP allows another user to forbid me from running it then I | > think that I'm on the safe side by saying that it's broken. | > | > Alfredo | | Doesn't Kuba mean | | /tmp/lyx --- owned by you The problem is then to make this happen. So the top dir would have to be /tmp/lyx- that you can lookup somewhere else, f.ex. in ~/.lyx/pipeinfo -- Lgb
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
Kuba Ober <[EMAIL PROTECTED]> writes: I'll have a look at aegis. At first glance it seems to be similar to BitKeeper? What are the differences? (And why doesn't Linus want to use aegis?) I'll go through the documentation. -- Lgb
Re: Patch: inverse search.
Alfredo Braunstein wrote:
> Kuba Ober wrote:
>
>> There's no reason for a globally fixed filename. At least, the file
>> name containing the user name or uid. That's what DCOP does in KDE.
>
> The file name containing only the user name or uid doesn't forbid
> another user to take it first.
>
> If DCOP allows another user to forbid me from running it then I
> think that I'm on the safe side by saying that it's broken.
>
> Alfredo
Doesn't Kuba mean
/tmp/lyx --- owned by you
Thereafter, only you can insert stuff (other dirs, files, pipes) in
/tmp/lyx. So, safe.
Different instance of lyx would insert unique dirs (based on pid)
containing unique dirs for each buffer --- only change there is that
the ROOT is /tmp/lyx, not /tmp
Different _versions_ of lyx would have pipes
/tmp/lyx/lyx-xyz.{in,out}
Seems safe to me.
We still have the same limitation that only one lyx instance can have
pipes connected, so Kuba's suggestion is to move the pipes into
/tmp/lyx/lyx-pid/pipe.{in,out}
Still safe but some magic is needed to find them.
--
Angus
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On środa 12 marzec 2003 11:45 am, you wrote: > On Wed, Mar 12, 2003 at 11:42:40AM -0500, Kuba Ober wrote: > > I guess that one has to have an attitude of burning bridges behind > > oneself in order to really enjoy Aegis. I had the pleasure of not having > > a VCS at all in my development, and starting right on with Aegis. I > > imagine that the CVS legacy may hurt, since your previous experience sort > > of limits your field of view -- you don't see things that Aegis makes > > possible. I, for one, find that there's a ton of things that Aegis just > > does almost by itself, whereas CVS needs some scripting in order to do > > that. > > Liek what? 0. You don't operate on the "diff" level. You operate on change level. Changes are self-contained units, like database transactions. 1. You don't diff by hand, aegis does diffing of only the files in the change for you. 2. The changes have to compile and build against your change, and against the baseline. CVS doesn't care. With Aegis, you never get a change that breaks builds! 3. If you specify it in your change attributes, the tests will be automatically run, and the change will fail to integrate if the tests fail. You don't have to invoke anything by hand, other than the aegis build command itself. Aegis makes sure that before an integration, the chosen tests are successful. 4. You always work on the local repository. You can integrate with the "server" any time you want. The "main repository" doesn't break your development -- you can merge your change with changes to the repository as often or as rarely as you want. E.g. if you're working on a change in the "HEAD" branch, and HEAD changes, and you feel like doing another change, the changes will be isolated and you don't have to integrate or merge your previous change just in order to do a new, unrelated change. You control isolation level of your changes throughout the devleopment cycle, a mandatory merge will only be enforced before the actual build. 5. Branching is trivial and you don't need to worry much if you feel like branching -- just create a branch, that's it. You do it at home, your branch can be local, you can commit the branch to the server too. 6. Given proper diff/patch tools (say fhist), integrating development branches is a breeze, and the change model employed by Aegis makes sure that you won't break the build, even if you're cross-integrating several branches and changes, from several repositories. 7. It's very easy to share "unofficial" branches, within the same project framework, across developers, without having them committed to the "main" server. Any subset of repositories (remember, they are all and always local!) can have any subset of additional branches, there's no need for the "main" repository to be priviledged in any way in that respect. In fact, you can almost do anything you feel like without having any connection to the net. You can merge and integrate with "main" or any other server when and how you feel like. I guess these are the main advantages. Here's how an imaginary session changing one file in lyx tree looks on Aegis: # set the project to "HEAD" $ ae_p lyx.1.4 # new change (with a GUI!) $ tkaenc # choose to work on that change (say it's change number 45) $ ae_c 45 # go to the development directory $ aecd # let's edit the readme $ aecp README $ vi README # let's wrap it up -- first do the diffs (otherwise the build will ask you to do it), then do the build [note that the build will do nothing here!], and finish the development $ aed && aeb && aede $ aedist -send | mail [EMAIL PROTECTED] # now, let's have say John review that change, suppose he downloaded the change to a file called c44 $ cat c44 | aedist -receive $ ae_p lyx.1.4 # john lists changes, and will see that change 45 awaits review $ ael c $ ae_c 45 # John wants to see the diffs, quite often that's sufficient $ aed && aedless # John gives his thumb-up for the change $ aerpass $ aedist -send | mail [EMAIL PROTECTED] # okay, now it's up to Lars to do the integration -- let's say Lars gets the change from email as well -- email serves just as an example, these can go to the "main" repository automatically $ cat c44r | aedist -receive $ ae_p lyx.1.4 # Lars lists changes, and sees change 45 awaiting integration $ ael c $ ae_c 45diff # let's make sure the change is actually Lars-clean ;-) $ aed && aedless # okay, it seems there's enough C++ and STL in it ;-), let's begin the integration $ aeib # build and integrate $ aeb && aeipass And that's it. Including formal review with documented rejection capability (the change goes back to the developer then), and repository administrator's final look and integration. Power-users can have developer and administrator powers, for example, so that they can do a "full commit" (as in CVS) themselves. Lesser people, who are only developers, only do the development that lands in the main repository awaiting review, and then integration.
Re: Patch: inverse search.
Kuba Ober wrote: > There's no reason for a globally fixed filename. At least, the file name > containing the user name or uid. That's what DCOP does in KDE. The file name containing only the user name or uid doesn't forbid another user to take it first. If DCOP allows another user to forbid me from running it then I think that I'm on the safe side by saying that it's broken. Alfredo
Re: [PATCH] InsetNewline
On Wed, Mar 12, 2003 at 06:51:20PM +0100, Lars Gullik Bj?nnes wrote: > | Heh, good one META_INSET is now == 0. Guess what we return on a > | bogus getChar(pos) ... > > Move to 1? I'm building that now. john
Re: [PATCH] InsetNewline
John Levon <[EMAIL PROTECTED]> writes: | On Wed, Mar 12, 2003 at 05:31:49PM +, John Levon wrote: | | > Forget it, I can't get the patch to work at all anyway, it segfaults | > looking for an inset at the end of a par that contains a newline. Lord | > knows why. | | Heh, good one META_INSET is now == 0. Guess what we return on a | bogus getChar(pos) ... Move to 1? | We have bogus getChar()s in a number of places. Can we at least start | making some console noise for them ? Yes. -- Lgb
Re: The DEPM discussion
On Wed, Mar 12, 2003 at 06:29:54PM +0100, Alfredo Braunstein wrote: > John, is it too hard to forbid them consistently? Isn't that DEPM ? OK theoretically we can suck in the remaining cases where we can have > 1 empty paragraph in a row. But I'm not going to put the effort in at the moment since it seems things are swinging your way. john
Re: [patch] env2.diff
Angus Leeming <[EMAIL PROTECTED]> writes: | Andre Poenitz wrote: | | > +#ifdef __GNUG__ | > +#pragma implementation | > +#endif | | Lars won't thank you for this ;-) Mmmm... I expect that was a fluke... -- Lgb
Re: [PATCH] InsetNewline
On Wed, Mar 12, 2003 at 05:31:49PM +, John Levon wrote: > Forget it, I can't get the patch to work at all anyway, it segfaults > looking for an inset at the end of a par that contains a newline. Lord > knows why. Heh, good one META_INSET is now == 0. Guess what we return on a bogus getChar(pos) ... We have bogus getChar()s in a number of places. Can we at least start making some console noise for them ? john
Re: [patch] env2.diff
Angus Leeming <[EMAIL PROTECTED]> writes: | There is no such legal entity as "The LyX Team" But it is fun to use that expression anyway. -- Lgb
Re: Patch: inverse search.
On środa 12 marzec 2003 11:29 am, Alfredo Braunstein wrote: > Kuba Ober wrote: > >> Why not? I don't want other users to break my lyx installation, why > >> should they be able to? > > > > Umm, your files in /tmp belong to you! Look at lyx's temporary directory > > already in /tmp. > > Of course they do. The problem is when they belong to some other user. > If the name is fixed someone else can creates a file with that name before > me. There's no reason for a globally fixed filename. At least, the file name containing the user name or uid. That's what DCOP does in KDE. > Lyx files in tmp have unique filenames (like lyx_tmpdir17385KEcV5v), and > then don't have this problem. Obviously ;-) Cheers, Kuba Ober
Re: lyx2lyx bug? [was: Revtex4 template: was OK, but is now broken !?!]
> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes: Dekel> On Tue, Mar 11, 2003 at 03:36:20PM +0100, Jean-Marc Lasgouttes Dekel> wrote: >> The revtex4 template contains snippets like: >> >> \begin_inset Info Use Thanks layout instead of inserting footnotes. >> Footnotes in the title will do weird things in REVTeX 4! \end_inset >> >> Obviously lyx2lyx faild to convert these into proper note insets. >> Is there any code to do the conversion? Dekel> I've just fixed that (please update status.13x). Dekel, can you have a further look at it? It still does not work. JMarc
Re: The DEPM discussion
On Wed, Mar 12, 2003 at 06:26:11PM +0100, Jean-Marc Lasgouttes wrote: > But having the possibility of leaving blank paragraphs here and there > without knowing whether they will still be there after saving is not > nice either. Do _you_ know which style layouts have KeepEmpty? What, and at least currently, you get this information right up front because lyx just removed the paragraph you were about type into ? Hmm... john
Re: The DEPM discussion
Jean-Marc Lasgouttes wrote: > Alfredo> With John's patch it's forbidden to enter two consecutive > Alfredo> newlines (the second does nothing), but you can obtain all > Alfredo> newlines you want by other methods. It seems weird. > > I agree with that. > > Alfredo> I think that we must choose between: > > Alfredo> - forbidding 2 consecutive newlines consistently > > This is what the old DEPM tried to do. Sorry, I meant 2 consecutive empty pars, not 2 consecutive newlines (so 3 consecutive newlines). The old code forbids 1 empty par apart from the cursor location, John's code forbids (somewhat inconsistently, and that was my criticism) two consecutive empty pars. (innocent question) John, is it too hard to forbid them consistently? > That's not good, since people will wonder why their nicely formatted > title page does not come out as expected. Add the same problem with > spaces (people trying to add spaces to do centering) and you get a lot > of confusion. I know, but I think that forbidding 2 empty pars _inconsistently_ will add to the confusion. > The suggestion of trying to remember what is currently happening > (horizontal cursor) seems intriguing and interesting to me. > Unfortunately, I do not have time to try it out now, since I spend my > time on 1.3.1cvs. The patch was good only to show what it feels like anyway. I don't know how hard would it be to solve all little (?) arising problems. John's patch seems to be in a quasi-working state. Alfredo
Re: [PATCH] InsetNewline
On Wed, Mar 12, 2003 at 05:21:13PM +, John Levon wrote: > I did ??? Where ? Forget it, I can't get the patch to work at all anyway, it segfaults looking for an inset at the end of a par that contains a newline. Lord knows why. john
Re: [patch] env2.diff
> "John" == John Levon <[EMAIL PROTECTED]> writes: >> This will exist in parallel to the current List/whatever for a few >> days. John> Hmm... and bibitem is still horked... Seconded. I can accept to see new features arriving and some temporary breaking, but if andre' already lost interest in making bibitem work _properly_, then I am worried. I will certainly disagree with removing of current code until andre can prove us that his new code can be at least as useful. JMarc
Re: The DEPM discussion
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> On Wed, Mar 12, 2003 at 05:40:05PM +0100, Jean-Marc Lasgouttes John> wrote: >> The suggestion of trying to remember what is currently happening >> (horizontal cursor) seems intriguing and interesting to me. >> Unfortunately, I do not have time to try it out now, since I spend >> my time on 1.3.1cvs. John> So this is a "no" vote for Alfredo's 1) (my patch) then is it ? It is not, because I did not try it. JMarc
Re: The DEPM discussion
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> On Wed, Mar 12, 2003 at 05:43:46PM +0100, Jean-Marc Lasgouttes John> wrote: 2) not annoy the user with vanishing paragraphs >> Are you sure this is _so_ annoying? I tend to like this behaviour John> I suspect you're used to it. It may be. But having the possibility of leaving blank paragraphs here and there without knowing whether they will still be there after saving is not nice either. Do _you_ know which style layouts have KeepEmpty? John> 4) encourage the user to understand that spacing is not created John> by pressing return >> That's the big point indeed. The horizontal cursor did that didn't >> it? John> Maybe. But it is new and quite unexpected. It *does* feel John> reasonably natural, but I am still worried. I have not tested it, so I cannot really comment. JMarc
Re: [PATCH] InsetNewline
On Wed, Mar 12, 2003 at 06:02:34PM +0100, Lars Gullik Bj?nnes wrote: > Also it seems that you removed all backward comp wrt reading old > files, if you do this, then lyx2lyx should be updated at the same > time. I did ??? Where ? john
Re: [patch] env2.diff
Andre Poenitz wrote: > +#ifdef __GNUG__ > +#pragma implementation > +#endif Lars won't thank you for this ;-) -- Angus
Re: [patch] env2.diff
Andre Poenitz wrote: > On Wed, Mar 12, 2003 at 04:55:25PM +, John Levon wrote: >> > +/* This file is part of >> > + * == >> > + * >> > + * LyX, The Document Processor >> > + * >> > + * Copyright 2002 The LyX Team. >> > + * >> > + *==*/ >> >> Old header. > > New is what? /** * \file dimension.C * This file is part of LyX, the document processor. * Licence details can be found in the file COPYING. * * \author André Pönitz * * Full author contact details are available in file CREDITS */ There is no such legal entity as "The LyX Team" -- Angus
Re: [PATCH] InsetNewline
John Levon <[EMAIL PROTECTED]> writes: | Probably won't build but it's a sketch ... comments ? | | Note we could make it have a really big width but this would actually | just complicated rowBreakPoint() and we'd *still* have to special case | it anyway. It removes a lot of lines good. You use one wrong construct: "new InsetNewline()" that should be: "new InsetNewline" (remvoe the parenthesis) Also it seems that you removed all backward comp wrt reading old files, if you do this, then lyx2lyx should be updated at the same time. -- Lgb
Re: [patch] environment-style insets
On Wed, Mar 12, 2003 at 05:57:18PM +0100, Lars Gullik Bjønnes wrote:
> | First patch is adding a LFUN to insert such a beast.
>
> This patch seem truncated.
Huch?
I'll try again.
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Index: src/LyXAction.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/LyXAction.C,v
retrieving revision 1.156
diff -u -p -r1.156 LyXAction.C
--- src/LyXAction.C 10 Mar 2003 09:46:23 - 1.156
+++ src/LyXAction.C 12 Mar 2003 15:54:06 -
@@ -168,6 +168,7 @@ void LyXAction::init()
N_("Choose Paragraph Environment"), ReadOnly },
{ LFUN_END_OF_SENTENCE, "end-of-sentence-period-insert",
N_("Insert end of sentence period"), Noop },
+ { LFUN_ENVIRONMENT_INSERT, "environment-insert", "", Noop },
{ LFUN_GOTOERROR, "error-next",
N_("Go to next error"), ReadOnly },
{ LFUN_REMOVEERRORS, "error-remove-all",
Index: src/commandtags.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/commandtags.h,v
retrieving revision 1.114
diff -u -p -r1.114 commandtags.h
--- src/commandtags.h 7 Mar 2003 18:44:53 - 1.114
+++ src/commandtags.h 12 Mar 2003 15:54:06 -
@@ -124,6 +124,7 @@ enum kb_action {
LFUN_NOTIFY,
LFUN_GOTOFILEROW, // Edmar 12/23/98
LFUN_INSERT_NOTE,
+ LFUN_ENVIRONMENT_INSERT,
LFUN_KMAP_OFF,
LFUN_KMAP_PRIM,
LFUN_KMAP_SEC,
Re: [patch] env2.diff
On Wed, Mar 12, 2003 at 05:50:38PM +0100, Andre Poenitz wrote: > > Old header. > > New is what? what you have in insethfill.h > > I assume you're going to be doing some major surgery here. > > This will exist in parallel to the current List/whatever for a few days. Hmm... and bibitem is still horked... john
Re: [patch] env2.diff
On Wed, Mar 12, 2003 at 05:50:38PM +0100, Andre' Poenitz wrote: > New is what? Found it: // -*- C++ -*- /** * \file insetenv.h * This file is part of LyX, the document processor. * Licence details can be found in the file COPYING. * * \author * * Full author contact details are available in file CREDITS */ Ok? -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: [patch] env2.diff
On Wed, Mar 12, 2003 at 04:55:25PM +, John Levon wrote: > > +/* This file is part of > > + * == > > + * > > + * LyX, The Document Processor > > + * > > + * Copyright 2002 The LyX Team. > > + * > > + *==*/ > > Old header. New is what? > > + : InsetCollapsable(bp) > > I assume you're going to be doing some major surgery here. Later. This will exist in parallel to the current List/whatever for a few days. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: [patch] environment-style insets
Andre Poenitz <[EMAIL PROTECTED]> writes: | I think I've the infra structure for "environment like" insets ready. | No rocket science actually. | | This will serve as a base for list, itemize, enumerate insets and this | could be the base of user defined environments via layout files. | | I'll feed that to the list in not-too-big chunks and commit with a few | minutes delay. | | First patch is adding a LFUN to insert such a beast. This patch seem truncated. -- Lgb
Re: [PATCH] InsetNewline
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> On Wed, Mar 12, 2003 at 04:39:04PM +, John Levon wrote: >> > You can probably make InsetNewline::noFontChange() return true, >> and > font setting will be closed and reopened later. >> >> OK John> Actually I don't really understand all this TYPEWRITER_FAMILY John> stuff.. I am not sure I remember about it either. You will probably have to try it out to see what is the difference between aaa\\ and aaa~\\ in typewriter mode. Newlines are very strange latex objects. BTW, in Inset::latex(), if you need to know the current font, you can do something like (taken from insetquote): lyx::pos_type curr_pos = parOwner()->getPositionOfInset(this); lyx::Assert(curr_pos != -1); LyXFont font = parOwner()->getFont(buf->params, curr_pos); JMarc
