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
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 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
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 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
> =
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 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
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
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: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
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 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 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
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
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
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
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
> "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?
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
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
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
> } else {
>> FuncRequest cmd2 = cmd;
>> cmd2.action = LFUN_INSET_INSERT;
>> dispatch(cmd2);
>> }
>
>Is that else-branch equivalent to
>
> } else {
>doInsertI
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
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
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
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
>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
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
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?
...
>> 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 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.
> >>
> >
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
> - case LFUN_MENURELOAD: {
I don't think either we should be loading menure... isn't this called
'a load of BS'?
- Martin
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
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 02:04:06PM +, Angus Leeming wrote:
> > Andre', off for a few days now.
> Have a good break.
Conference.
Talk.
*sigh*
Andre'
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: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 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.
>
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
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
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
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
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.
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
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
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
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 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
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 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
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
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
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
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
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
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
57 matches
Mail list logo
