Angus Leeming wrote:
> The formatting here has gone to pot:
ok. I'll fix this.
> This seems wrong. Shouldn't it be specialised for Jurabib?
> Index: src/frontends/controllers/biblio.C
> switch (styles[i]) {
> case CITE:
> + str = author;
> +
Juergen Spitzmueller wrote:
> > This seems wrong. Shouldn't it be specialised for Jurabib?
> > Index: src/frontends/controllers/biblio.C
> > switch (styles[i]) {
> > case CITE:
> > + str = author;
> > + break;
> > +
> >
> What's the point on having
>
> class duh {
> public:
>int & foo() { return foo_; }
> private:
>int foo_;
> }
>
> What's the advantage wrt. have a public foo? (I can only see
> disadvantages)
One can write
duh x:
++x.foo();
without writing a dozen 'modifiers'
duh::increme
Juergen Spitzmueller wrote:
Jürgen, this looks very good! A few minor questions only.
Angus
The formatting here has gone to pot:
+string const BufferParams::babelCall(string const & lang_opts) const
+{
+ string tmp = lyxrc.language_package;
+ if (!lyxrc.language_global_option
I'd like to add support for the bibtex package jurabib (www.jurabib.org, see
bugzilla request 408).
Jurabib has been developped for law studies, to support short title
references, but in the meantime, it has evolved to a general bibtex tool for
human scientists, the best one around IMHO. It supp
On Friday 05 March 2004 14:32, Alfredo Braunstein wrote:
>
> Oh, the policy seems to be to never change implementation details, just
> the interface.
>
> Alfredo
>
> PS: I won't close the tag.
That will get you a beer in our next meeting.
--
José Abílio
LyX and docbook, a perfect match. :-)
Juergen Spitzmueller wrote:
> > By all means. The patch looks good to me.
>
> OK, I take this as a "yes" since you are the citation master.
It's in. Next patch follows soon...
Jürgen.
Jose' Matos wrote:
> Suppose you later change the implementation and not the interface. That
> is
> not possible with a public data member.
Possibly, but you still have limitations (return a reference). In that case
I would expect an "int foo()" and an "void foo(int)" accessors.
> And don'
Angus Leeming wrote:
> > can I apply this if I bump the file format to 230? I have some more
> > citation features (i.e. jurabib support) and I'd like to proceed.
>
> By all means. The patch looks good to me.
OK, I take this as a "yes" since you are the citation master.
Jürgen.
Juergen Spitzmueller wrote:
> Juergen Spitzmueller wrote:
>> this patch finally adds a second option to insetcommand and thus
>> enables natbib's "before" option.
>
> can I apply this if I bump the file format to 230? I have some more
> citation features (i.e. jurabib support) and I'd like to pro
Juergen Spitzmueller wrote:
> OK, see it. Yes, we have to reselect since the whole browser content gets
> updated (and the QListViewItem id changes). The attached patch fixes this
> (there's no easier way AFAICS) and an off-by-one error in the qt-branches
> dialog. I'll apply this since this is re
On Fri, Mar 05, 2004 at 09:55:30AM +0100, Alfredo Braunstein spake thusly:
> > OK to commit this?
>
> It's fine by me (if that means something :-)).
>
> Alfredo
It's in, as it isn't exactly controversial.
- Martin
pgp0.pgp
Description: PGP signature
Juergen Spitzmueller wrote:
> this patch finally adds a second option to insetcommand and thus enables
> natbib's "before" option.
can I apply this if I bump the file format to 230? I have some more citation
features (i.e. jurabib support) and I'd like to proceed.
Regards,
Jürgen.
Alfredo Braunstein wrote:
> Sorry, I mean that the branch gets deselected after activate/deactivate or
> color change. I don't know if it's a bug (I don't like it, though).
OK, see it. Yes, we have to reselect since the whole browser content gets
updated (and the QListViewItem id changes). The at
On Friday 05 March 2004 12:14, Alfredo Braunstein wrote:
> What's the point on having
>
> class duh {
> public:
> int & foo() { return foo_; }
> private:
> int foo_;
> }
>
> What's the advantage wrt. have a public foo? (I can only see
> disadvantages)
Suppose you later change the
Alfredo Braunstein wrote:
> What's the point on having
>
> class duh {
> public:
> int & foo() { return foo_; }
> private:
> int foo_;
> }
>
> What's the advantage wrt. have a public foo? (I can only see
> disadvantages)
(Possible) practical advantage:
int & duh::foo()
{
#ifd
What's the point on having
class duh {
public:
int & foo() { return foo_; }
private:
int foo_;
}
What's the advantage wrt. have a public foo? (I can only see disadvantages)
Alfredo
Juergen Spitzmueller wrote:
> Alfredo Braunstein wrote:
>> Btw, the qtlyx interface is slightly different but still a bit broken.
>> The selected branch goes off unexpectedly after every action.
>
> Can you elaborate a bit please? I don't see this.
Sorry, I mean that the branch gets deselected a
Alfredo Braunstein wrote:
> Btw, the qtlyx interface is slightly different but still a bit broken.
> The selected branch goes off unexpectedly after every action.
Can you elaborate a bit please? I don't see this.
Jürgen.
On Fri, Mar 05, 2004 at 09:55:30AM +0100, Alfredo Braunstein spake thusly:
> Martin Vermeer wrote:
>
> > Actually it's not as bad as it looks. The problem was between chair
> > and keyboard, and in an AWFUL user interface.
> >
> > See patch. The first section is just removing a doubling-up of c
Martin Vermeer wrote:
> Actually it's not as bad as it looks. The problem was between chair
> and keyboard, and in an AWFUL user interface.
>
> See patch. The first section is just removing a doubling-up of code
> and functionally neutral. The second section is what matters.
>
> The user interfa
21 matches
Mail list logo
