On Wed, Nov 12, 2003 at 09:24:31PM -0800, Kayvan A. Sylvan wrote:
> Nothing happens on Edit->Paragraph Settings
>
> Messages on console:
>
> LyXFunc::dispatch: cmd: action: 123 arg: '' x: 0 y: 0
>
> LCursor::dispatch:
>
> trying to dispatch to main text 0x100b2cd0
> LyXText::dispatch: cmd: a
Hi,
something is wrong which the POT file creation! I can't believe that two
fifth of all messages have gone during the code cleanup
Michael
file=./`echo de | sed 's,.*/,,'`.gmo \
&& case "/usr/bin/msgfmt" in \
*/msgfmt) rm -f $file && /usr/bin/msgfmt --statistics -o $file
de.po
Hi,
here comes the current list of unused symbols (functions/variables)
(with QT frontend). It looks like you have carefully removed all old
cruft during your cursor cleanup!
Michael
++
(anonymous namespace)::Correction::***l
On Wednesday 12 November 2003 8:11 pm, Martin Vermeer wrote:
> On Wed, Nov 12, 2003 at 10:51:02AM +, Angus Leeming spake thusly:
> > As these are your babies, perhaps you'll add them? May I suggest:
>
> Patch attached for the karma-endowed :-(
... committed.
Angus
Jean-Marc Lasgouttes wrote:
Andre> This does look simple enough. Is there a reason we don't use it
Andre> already?
With which version of gcc/binutils and on which platforms does this work?
It works definitely with gcc 3.3.1 and binutils 2.14.90.0.5 on SuSE 9.0.
It also worked with gcc 3.2.2 on Su
Problem:
tex2lyx currently cannot handle commands with optional arguments, because
the brackets are translated to normal text. LyX then produces {[} instead
of [. One example where this happens is the userguide.
Solution 1:
Call something like
string opts;
string opt = p.getOpt();
while (opt.si
On Thu, Nov 13, 2003 at 03:01:21PM +, Angus Leeming spake thusly:
> > If no shout, I'll commit a bit later.
>
> Please do.
So done.
- Martin
pgp0.pgp
Description: PGP signature
This patch sanitizes selection handling.
Basically removes all InsetText special case selection-handling code and
adjust the LyXText code a bit to handle also insets.
There are two remaining problems (selection related, but unrelated with the
patch):
- LFUN_MOUSE_RELEASE events get dispatched to
On Thursday 13 November 2003 08:46 am, [EMAIL PROTECTED] wrote:
> > - case LFUN_MENURELOAD: {
>
> I don't think either we should be loading menure... isn't this called
> 'a load of BS'?
>
>
C'mon, if we all didn't have some fun in the process it would be no fun,
right? :)
Cheers, Kuba Obe
John Levon wrote:
>> Unfortunately I suspect that the underlying obvious way of getting 100%
>> familiarity will not do much good to LyX itself...
>
> It would improve compile times though.
Nice to see some optimism nowadays... ;-)
Alfredo
On Thu, Nov 13, 2003 at 04:30:50PM +0100, Alfredo Braunstein wrote:
> > Note that removing code that you are not familiar with increases your
> > average familiarity with the code ;-)
>
> Unfortunately I suspect that the underlying obvious way of getting 100%
> familiarity will not do much good t
I've been trying to get a new version of cocoAspell, a
system-spellchecker for MacOS-10.3, to work with LyX/Mac-1.3.3 -- so
far with no luck.
As a preface, the earlier version of cocoAspell worked with LyX-1.3.3
on MacOS-10.2. The new version works as a system spellchecker on
MacOS-10.3, from
Andre Poenitz wrote:
>> I don't have all that urge for commiting, and I prefer to have some
>> review (specially if the change implies removal of a lot of code I'm not
>> very familiar with :-> ).
>
> Note that removing code that you are not familiar with increases your
> average familiarity with
On Thu, Nov 13, 2003 at 03:30:57PM +0100, Lars Gullik Bj?nnes wrote:
> Anyhow we shouldn't use FIXME for that purpose, "UNDOCUMENTED" would
> be better.
Fine
john
--
Khendon's Law:
If the same point is made twice by the same person, the thread is over.
On Thu, Nov 13, 2003 at 03:24:51PM +0100, Andre Poenitz wrote:
> I'd prefer the documentation instead of the 'FIXME', but that's just
> some personal preference.
Maybe after you're finished the code will be understandable enough to
actually allow documentation :)
regards
john
--
Khendon's Law
Martin Vermeer wrote:
> OK, here's my latest including a local LFUN_INSET_INSERT.
Thank you.
> If no shout, I'll commit a bit later.
Please do.
--
Angus
John Levon <[EMAIL PROTECTED]> writes:
| On Thu, Nov 13, 2003 at 09:01:48AM +0100, Andre Poenitz wrote:
>
>> > Wht the FIXME?
>>
>> Somebody decided that /// FIXME looks better than plain ///...
>
| If you mean me, that's not true. I decided that things that needed docs
| shoould have FIXME, a
Andre Poenitz <[EMAIL PROTECTED]> writes:
| E.g just one instead of three per .
>
| Plus removal of deleteLyXText
>
| Plus caching 'beginOfBodyPos'.
>
| We should be faster than 1.3 now..
You do so much reindetation that it is impossible to see what you are
actually changing.
but I noticed that
On Thu, Nov 13, 2003 at 02:04:06PM +, Angus Leeming spake thusly:
>
> Andre Poenitz wrote:
>
> > On Thu, Nov 13, 2003 at 01:48:37PM +, Angus Leeming wrote:
> >> I am all in favour of the general thrust (to get things working)
> >> but would want LFUN_INSET_INSERT to be moved across too.
>
On Thu, Nov 13, 2003 at 02:19:52PM +, John Levon wrote:
> On Thu, Nov 13, 2003 at 09:01:48AM +0100, Andre Poenitz wrote:
>
> > > Wht the FIXME?
> >
> > Somebody decided that /// FIXME looks better than plain ///...
>
> If you mean me, that's not true.
If I meant you, I would have used the
On Thu, Nov 13, 2003 at 09:01:48AM +0100, Andre Poenitz wrote:
> > Wht the FIXME?
>
> Somebody decided that /// FIXME looks better than plain ///...
If you mean me, that's not true. I decided that things that needed docs
shoould have FIXME, and anything else should just have a blank line
abov
On Thu, Nov 13, 2003 at 02:04:06PM +, Angus Leeming wrote:
> > Andre', off for a few days now.
> Have a good break.
Conference.
Talk.
*sigh*
Andre'
Andre Poenitz wrote:
> On Thu, Nov 13, 2003 at 01:48:37PM +, Angus Leeming wrote:
>> I am all in favour of the general thrust (to get things working)
>> but would want LFUN_INSET_INSERT to be moved across too.
>> Pleaeee!
>
> So why don't you just do it.
> You are a big boy after
On Thu, Nov 13, 2003 at 01:48:37PM +, Angus Leeming wrote:
> I am all in favour of the general thrust (to get things working) but
> would want LFUN_INSET_INSERT to be moved across too.
> Pleaeee!
So why don't you just do it.
You are a big boy after all.
Andre', off for a few day
> - case LFUN_MENURELOAD: {
I don't think either we should be loading menure... isn't this called
'a load of BS'?
- Martin
Andre Poenitz wrote:
> On Thu, Nov 13, 2003 at 01:26:53PM +, [EMAIL PROTECTED]
> wrote:
>> ..
>>
>> >> Attached a patch instrumented with asserts.
>> >>
>> >> Let's check this in. We'll hear about it soon enough if this
>> >> code is
>> >> in use somewhere... I gave it a quick test, but didn
On Thu, Nov 13, 2003 at 01:26:53PM +, [EMAIL PROTECTED] wrote:
> ..
>
> >> Attached a patch instrumented with asserts.
> >>
> >> Let's check this in. We'll hear about it soon enough if this code is
> >> in use somewhere... I gave it a quick test, but didn't manage to
> >> trigger it.
> >>
> >
...
>> Attached a patch instrumented with asserts.
>>
>> Let's check this in. We'll hear about it soon enough if this code is
>> in use somewhere... I gave it a quick test, but didn't manage to
>> trigger it.
>>
>> (Is there a way to check more systematically whether a piece of code
>> _ever_ get
On Thu, Nov 13, 2003 at 02:58:01PM +0200, Martin Vermeer wrote:
> On Thu, Nov 13, 2003 at 12:13:14PM +, [EMAIL PROTECTED] spake thusly:
>
> > It doesn't get called, that's what's wrong with it.
> >
> > What implications does deleting the above code from
> > BufferView::Pimpl::dispatch have?
On Thu, Nov 13, 2003 at 12:13:14PM +, [EMAIL PROTECTED] spake thusly:
> It doesn't get called, that's what's wrong with it.
>
> What implications does deleting the above code from
> BufferView::Pimpl::dispatch have? I haven't tried it.
Attached a patch instrumented with asserts.
Let's ch
>Hmmm. and where is LFUN_INSET_APPLY currently handled? It certainly
>isn't in LyXText::dispatch and it does exist somewhere...
>
>Ok, got it. It's in BufferView_pimpl.C.
>
>Martin, I note that your patch doesn't delete this copy of the LFUN
>handler. If you're going to add it to LyxText::dispatc
Andre Poenitz wrote:
> On Thu, Nov 13, 2003 at 10:15:03AM +, Angus Leeming wrote:
>> Andre Poenitz wrote:
>> > Is that else-branch equivalent to
>> >
>> > } else {
>> > doInsertInset(this, cmd, true, false);
>> > }
>> > br
On Thu, Nov 13, 2003 at 10:15:03AM +, Angus Leeming wrote:
> Andre Poenitz wrote:
> > Is that else-branch equivalent to
> >
> > } else {
> > doInsertInset(this, cmd, true, false);
> > }
> > break;
>
> Depends what doInsert
On Thu, Nov 13, 2003 at 10:07:46AM +, [EMAIL PROTECTED] wrote:
>
> > } else {
> >> FuncRequest cmd2 = cmd;
> >> cmd2.action = LFUN_INSET_INSERT;
> >> dispatch(cmd2);
> >> }
> >
> >Is that el
Andre Poenitz wrote:
> Is that else-branch equivalent to
>
> } else {
> doInsertInset(this, cmd, true, false);
> }
> break;
Depends what doInsertInset does with cmd doesn't it... Ie, does it
check that it is dealing with LFUN
> } else {
>> FuncRequest cmd2 = cmd;
>> cmd2.action = LFUN_INSET_INSERT;
>> dispatch(cmd2);
>> }
>
>Is that else-branch equivalent to
>
> } else {
>doInsertI
On Thu, Nov 13, 2003 at 09:50:30AM +, Angus Leeming wrote:
> Martin Vermeer wrote:
>
> > On Wed, Nov 12, 2003 at 05:10:41PM +, Angus Leeming spake
> > thusly:
> >
> > ...
> >
> > Progress!
> >
> > Now I have the attached, and the dialog comes up and if you enter a
> > string there, it b
Martin Vermeer wrote:
> On Wed, Nov 12, 2003 at 05:10:41PM +, Angus Leeming spake
> thusly:
>
> ...
>
> Progress!
>
> Now I have the attached, and the dialog comes up and if you enter a
> string there, it becomes the inset name. I.e., the "APPLY: no inset"
> branch now functions. And not on
Andre Poenitz wrote:
>> This is true.
>> I was a bit reluctant because I was thinking some awful table behaviour
>> I've suffered: if the mouse goes out, the selection jumps to a higher
>> level,
>
> That's what math does..
>
>> but there's no going back, so you are normally stuck with a
>> sel
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> This does look simple enough. Is there a reason we don't use it
Andre> already?
With which version of gcc/binutils and on which platforms does this work?
On Thu, Nov 13, 2003 at 10:11:20AM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > PS: The rule was: If nobody shouts within a certain amount of time, go.
>
> I don't have all that urge for commiting, and I prefer to have some review
> (specially if the change implies removal of a l
On Thu, Nov 13, 2003 at 10:03:49AM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> >> For text, the other is 1.3.x behaviour. If you insist on yours, I think
> >> we should fix things a bit, because we don't allow selections ending at
> >> different levels, so the start of the selectio
Andre Poenitz wrote:
> PS: The rule was: If nobody shouts within a certain amount of time, go.
I don't have all that urge for commiting, and I prefer to have some review
(specially if the change implies removal of a lot of code I'm not very
familiar with :-> ).
Alfredo
Andre Poenitz wrote:
>> For text, the other is 1.3.x behaviour. If you insist on yours, I think
>> we should fix things a bit, because we don't allow selections ending at
>> different levels, so the start of the selection has to be adjusted.
>
> I don't insist on 'mine' right now. Just making it
On Thu, Nov 13, 2003 at 11:08:31AM +0200, Martin Vermeer spake thusly:
> Do you see anything obviously wrong with it
> case LFUN_INSET_INSERT: {
> string const name = cmd.getArg(0);
> -
> +
> if (name == "bibitem") {
I already do :-(
Consider t
On Thu, Nov 13, 2003 at 11:08:31AM +0200, Martin Vermeer wrote:
> Do you see anything obviously wrong with it (I'm really not very
> familiar with this corner of the code)
Me neither, smells like Angus ;-)
> or shall I just put it in?
It does not look wrong (apart from the usual whitespace...),
On Thu, Nov 13, 2003 at 09:05:13AM +0100, Andre Poenitz spake thusly:
> The temporary freexe I was asking for is over. I just did not want that
> monster patch to be broken by some variable renaming or similar
> 'unimportant' stuff.
>
> Feel free to continue your work now.
>
> Andre'
Thanks An
On Thu, Nov 13, 2003 at 09:48:54AM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > It's very convenient.
>
> For text, the other is 1.3.x behaviour. If you insist on yours, I think we
> should fix things a bit, because we don't allow selections ending at
> different levels, so the s
Andre Poenitz wrote:
> It's very convenient.
For text, the other is 1.3.x behaviour. If you insist on yours, I think we
should fix things a bit, because we don't allow selections ending at
different levels, so the start of the selection has to be adjusted.
[I don't think it's so important for tex
On Thu, Nov 13, 2003 at 09:20:52AM +0100, Alfredo Braunstein wrote:
> Alfredo Braunstein wrote:
>
> > I've removed all inset-dependent fitCursor functions,
> > and put toghether all fitcursor-related functions in screen.C in only one,
> > putting the smart tall row handling there (with some code s
On Thu, Nov 13, 2003 at 08:55:56AM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > On Wed, Nov 12, 2003 at 03:51:12PM +0100, Alfredo Braunstein wrote:
> >> shouldn't LFUN_MOUSE_MOTION be dispatched to the inset having the cursor?
> >> Right now it's dispatched to whatever it's under
Alfredo Braunstein wrote:
> I've removed all inset-dependent fitCursor functions,
> and put toghether all fitcursor-related functions in screen.C in only one,
> putting the smart tall row handling there (with some code simplification
> and nice variable names).
>
> Now the same routine is used fo
On Wed, Nov 12, 2003 at 11:39:01AM +0100, Michael Schmitt wrote:
> Hello,
>
> from time to time, we discuss about the same problem again: Linking with
> debug information is sooo time-consuming.
>
> I would like to remind you of a very simple solution:
>
>
> Index: config/lyxinclude.m4
> =
On Wed, Nov 12, 2003 at 09:46:24AM +0200, Martin Vermeer wrote:
>
> Okay I know, there are still pending regressions from André's patch...
> but this was OK before the patch, and quite orthogonal to it, so I
> think I'll just check it in later today.
The temporary freexe I was asking for is over
On Tue, Nov 11, 2003 at 03:23:16PM +, Angus Leeming wrote:
> Alfredo Braunstein wrote:
>
> > I've removed all inset-dependent fitCursor functions,
> > and put toghether all fitcursor-related functions in screen.C in
> > only one, putting the smart tall row handling there (with some code
> > si
Andre Poenitz wrote:
> On Wed, Nov 12, 2003 at 03:51:12PM +0100, Alfredo Braunstein wrote:
>> shouldn't LFUN_MOUSE_MOTION be dispatched to the inset having the cursor?
>> Right now it's dispatched to whatever it's under the event position as
>> any mouse click, but this looks bogus to me.
>
> Why
On Wed, Nov 12, 2003 at 03:51:12PM +0100, Alfredo Braunstein wrote:
> shouldn't LFUN_MOUSE_MOTION be dispatched to the inset having the cursor?
> Right now it's dispatched to whatever it's under the event position as any
> mouse click, but this looks bogus to me.
Why?
Doing it otherwise would mea
57 matches
Mail list logo
