I'll have a look ASAP
On Mon, Aug 3, 2015 at 4:51 AM, LyX Ticket Tracker wrote:
> #9708: Cannot step selection back after selecting down out of a multi-line
> inset
> ---+-
> Reporter: skostysh | Owner: lasgouttes
> Type: defect |
+1 nice!
A/
On Wed, May 27, 2015 at 9:55 AM, Enrico Forestieri wrote:
> On Tue, May 26, 2015 at 07:34:35AM -0400, Scott Kostyshak wrote:
>> Attached is a screenshot of how the LyX banner looks for me on Ubuntu
>> with Qt 5.5dev.
>
> What about the attached one?
>
> --
> Enrico
On Fri, Feb 27, 2015 at 6:17 PM, Scott Kostyshak wrote:
> I think Richard is talking about what you are interested in, which is this bug
> http://www.lyx.org/trac/ticket/2346
> which was fixed by Alfredo and is in 2.2dev but is not in 2.1.3.
Yes, maybe also #9289 and #9291
A/
On Thu, Feb 26, 2015 at 1:02 AM, wrote:
> Tue, Feb 24, 2015 at 11:33 PM, wrote:
>> > I am a LyX lover. However ... :)
>> >
>> > ... inside equations and tables, Lyx's cursor movement "rules" drive me
>> nuts! I dislike mousing, and prefer cursor-movement keys as more
>> predictable and requirin
On Tue, Feb 24, 2015 at 11:33 PM, wrote:
> I am a LyX lover. However ... :)
>
> ... inside equations and tables, Lyx's cursor movement "rules" drive me nuts!
> I dislike mousing, and prefer cursor-movement keys as more predictable and
> requiring less conscious control. But the key-based motion
If you wrote a "This is a test" message to the list, then it worked.
If you wrote something else, then it didn't!
A/
On Sat, Jan 17, 2015 at 7:02 PM, Richard Heck wrote:
>
> This is a test.
>
It's not for me, or at least not anymore.
A/
On Mon, Dec 29, 2014 at 12:54 PM, Kornel Benko wrote:
>
> Kornel
(-1)*(-1)
A/
On Mon, Dec 8, 2014 at 9:24 AM, Jean-Marc Lasgouttes wrote:
> Le 08/12/2014 09:00, Jürgen Spitzmüller a écrit :
>>
>> Today, I'll have to agree that I disagree with what I stated yesterday.
>> Now I
>> agree with JMarc and Richard. Not sure if I agree with Alfredo, though.
>
>
> +1
On Sun, Dec 7, 2014 at 8:09 PM, Jean-Marc Lasgouttes wrote:
> Le 07/12/2014 17:22, Richard Heck a écrit :
>>>
>>> The point is that InsetLayout const & DocumentClass::insetLayout()
>>> does not
>>> find Flex:Foo, but only Foo.
>>
>>
>> No, it will find Flex:Emph, for example, from the Logical Mark
Btw, what you describe is similar to the behaviour of gedit (gtk), but
LyX behaviour is the same as the one of kate (qt)... So it seems that
there is no general consensus. There is a notable difference in what
happens when you move (arrows) with a selection going on: with the
current behaviour, the
As the choices are exclusive, shouldn't this be a radio button instead
of individual checkmarks? In this way it would be self explanatory --
or I am missing the point completely?
A/
On Wed, Nov 12, 2014 at 11:52 AM, Kornel Benko wrote:
> Am Mittwoch, 12. November 2014 um 10:30:53, schrieb Richar
Excellent, thanks! What could be a good way of avoiding this mess in
the future? Maybe put this code in a Buffer::setDocumentClass function
and use always that instead of the BufferParams one? I barely know
what I'm talking about here...
A/
On Tue, Nov 11, 2014 at 9:08 PM, Georg Baum
wrote:
> R
On Wed, Oct 22, 2014 at 5:47 AM, Cyrille Artho wrote:
> In my experience, false positives regarding uninitialized memory are
> extremely rare. So it's most likely a real problem. Maybe the code refers to
> stack-allocated memory or heap memory that was used just before, so the data
> is still "in
n Mon, Oct 20, 2014 at 9:08 PM, Richard Heck wrote:
> On 10/20/2014 01:25 PM, Alfredo Braunstein wrote:
>>
>> Running under valgrind, open LyX (master branch), create a new
>> document, write 'a', select it and copy it; valgrind complains (see
>> below). I get it
Running under valgrind, open LyX (master branch), create a new
document, write 'a', select it and copy it; valgrind complains (see
below). I get it consistently.
A second copy doesn't give any problem, it's just the first one that
does. The problem seems related to a badly initialized temporary
bu
On Sun, Oct 19, 2014 at 4:16 PM, Jean-Marc Lasgouttes
wrote:
> Le 17/10/2014 18:56, Alfredo Braunstein a écrit :
>>
>> I see. IMO the LFUN way is preferable. I'll give one use case where I
>> would find this useful: when writing a document with length
>> constra
igures
and equations, that are counted separately with their own measure...
On Sat, Oct 18, 2014 at 3:03 PM, Jürgen Spitzmüller wrote:
> Alfredo Braunstein wrote:
>> I see. IMO the LFUN way is preferable. I'll give one use case where I
>> would find this useful: when
Just tested and you're right.
A/
On Fri, Oct 17, 2014 at 9:23 PM, Pavel Sanda wrote:
> Alfredo Braunstein wrote:
>> Btw, it would be also nice to have selection-bound statistics (e.g. in
>> some journals / grant calls there are rigid bounds for each section or
>>
On Fri, Oct 17, 2014 at 6:56 PM, Alfredo Braunstein wrote:
> I see. IMO the LFUN way is preferable. I'll give one use case where I
> would find this useful: when writing a document with length
> constraints (e.g. # words, # chars), it would be nice to have the
> information acc
).
A/
On Fri, Oct 17, 2014 at 6:14 PM, Pavel Sanda wrote:
> Alfredo Braunstein wrote:
>> Sorry for the dumb question, but what is InsetInfo good for (in terms
>> of usecase). It seems like a very strange concept IMHO. Why can't it
>> be e.g a dialog or a panel?
>
> It&
On Fri, Oct 17, 2014 at 9:57 AM, Jean-Marc Lasgouttes
wrote:
> Le 17/10/2014 04:09, Pavel Sanda a écrit :
>> Jean-Marc Lasgouttes wrote:
>>
>> What usecase lead to this lfun? If the point is to store this info in
>> document
>> more proper way would be insetinfo.
Sorry for the dumb question, but
> OK, but what is the link between InsetERT not having a ::latex method ans
> not outputting anything? The InsetText::latex is sufficiently flexible to
> handle it. Likewise for many insets derived from InsetCommand (label,
> bibitem...).
I forgot to answer this. Putting this default latex method
On Wed, Oct 15, 2014 at 11:37 AM, Jean-Marc Lasgouttes
wrote:
> Le 15/10/2014 11:16, Alfredo Braunstein a écrit :
>>>
>>> I don't understand: I guess many inset just inherit their ::latex method.
>>> What is the risk exactly.
>>
>>
>> Advanced
On Wed, Oct 15, 2014 at 10:31 AM, Jean-Marc Lasgouttes
wrote:
> Le 15/10/2014 09:17, Alfredo Braunstein a écrit :
>>
>> Thanks a lot Jürgen. The following insets do not have a ::latex
>> implementation and thus are at a risk of dataloss in advanced s&r
>> (although
.cpp
InsetLabel.cpp
InsetListingsParams.cpp
InsetMarginal.cpp
InsetPreview.cpp
InsetScript.cpp
InsetTOC.cpp
On Tue, Oct 14, 2014 at 11:37 PM, Jürgen Spitzmüller wrote:
> 2014-10-14 22:25 GMT+02:00 Alfredo Braunstein:
>>
>> Btw, are there other insets besides InsetNote that could produce n
On Tue, Oct 14, 2014 at 7:47 PM, Alfredo Braunstein wrote:
> The problem is that InsetNote do not produce any text nor latex
> output, so it can be matched freely by the regexp. The patch
> adds an output_notes member of OutputParam, default to false, and
> setting to true on advance
On Tue, Oct 14, 2014 at 8:04 PM, Scott Kostyshak wrote:
> On Thu, Oct 9, 2014 at 8:35 AM, Scott Kostyshak wrote:
>> Francisco Redondo recently sent a PDF (and will send the corresponding
>> LyX file) for an xypic example file, but it is not a direct
>> translation of the English xypic manual. Wha
The problem is that InsetNote do not produce any text nor latex
output, so it can be matched freely by the regexp. The patch
adds an output_notes member of OutputParam, default to false, and
setting to true on advanced s&r. I set it to true also for the
stringification of the search buffer, so now
ok, done.
A/
On Tue, Oct 14, 2014 at 5:33 PM, Richard Heck wrote:
> On 10/14/2014 11:17 AM, Alfredo Braunstein wrote:
>>
>> On Tue, Oct 14, 2014 at 8:51 AM, Alfredo Braunstein
>> wrote:
>>>
>>> On Mon, Oct 13, 2014 at 6:27 PM, Jean-Marc Lasgouttes
&g
On Tue, Oct 14, 2014 at 8:51 AM, Alfredo Braunstein wrote:
> On Mon, Oct 13, 2014 at 6:27 PM, Jean-Marc Lasgouttes
> wrote:
>> Le 13/10/2014 18:15, Alfredo Braunstein a écrit :
>>>>>
>>>>> The fix however seems bogus to me:
>>&g
Alfredo Braunstein wrote:
> The second chunk is a fix to #9291 "Cannot exit table when selecting
> with keyboard to right or left". The problem was simply that the
> default status for the cursor in the call to *::doDispatch is
> dispatched... (btw, there are many cur.d
On Mon, Oct 13, 2014 at 6:27 PM, Jean-Marc Lasgouttes
wrote:
> Le 13/10/2014 18:15, Alfredo Braunstein a écrit :
>>>>
>>>> The fix however seems bogus to me:
>>>
>>>
>>>
>>>> -cur.forwardPos();
>>>>
> Yes, more opinions would be nice. There is some good feedback in the
> following message supporting the change, from a regular user of those
> insets (in Spanish):
> http://www.mail-archive.com/lyx-es@lists.lyx.org/msg00061.html
Sold, to the spanish-speaking gentleman with the appropriate feedba
On Mon, Oct 13, 2014 at 5:39 PM, Jean-Marc Lasgouttes
wrote:
> Le 13/10/2014 14:29, Alfredo Braunstein a écrit :
>>
>> The fix however seems bogus to me:
>
>
>> -cur.forwardPos();
>> +cur.top().forwardPos();
>
>
> Why bogu
On Mon, Oct 13, 2014 at 12:00 AM, Scott Kostyshak wrote:
> Good find. I think this is because of a commit I made that enables the
> submenus even if all items are greyed out:
Cool, this was indeed a good (overdue) change :-).
> If there are no other opinions on this in the next few days, I will
The problem was indeed correctly identified by JM in changeset 7c3d1d7:
"The problem is the use of cursor movement methods to update cursor.
Cursor::forwardPos() steps into insets, which is not always what we
want. The problem here is that there is a math inset just after the
accepted change, and
On Sun, Oct 12, 2014 at 9:58 PM, Scott Kostyshak wrote:
> If you go to Insert > Float > Figure Wrap Float, it does not float by
> default. The two "Float" words in that process led me to assume that
> it would wrap by default. One must go to settings and click on "Allow
> floating". I was surprise
The second chunk is a fix to #9291 "Cannot exit table when selecting
with keyboard to right or left". The problem was simply that the
default status for the cursor in the call to *::doDispatch is
dispatched... (btw, there are many cur.dispatched() statements there
that may be superfluous).
The fir
Richard Heck wrote:
> Do you have commit rights still? If so, I'd suggest you go ahead and
> commit to master. Then create the bug and mark it fixedinmaster so we
> can remember to add this to 2.1.x at some point.
Done.
A/
Jean-Marc Lasgouttes wrote:
> I am not sure of whether your patch is the right one, but we could apply
> it and see what happens in master.
Done. I've made the same change also to checkAndActivateInsetVisual, I
presume for visual navigation inside RTL, but I did not test it (I don't
know how).
Jean-Marc Lasgouttes wrote:
> I am not sure of whether your patch is the right one, but we could apply
> it and see what happens in master.
Of course the patch is correct! It is the rest of the code that may be wrong
;-)
> If you send a public ssh key to me, I'll give you git commit rights.
I
> This is great! I have also been frustrated by this. Thank you for the
> patch. It worked well for me in limited testing.
>
> I think your bug report might be a duplicate of
> http://www.lyx.org/trac/ticket/2346
Yep, you are right, thanks. Humm, how do I mark it as duplicate of
2346? I see only a
Continuing with a series of semi-infuriating navigation and selection
issues.
When starting a selection inside an inset (e.g. footnote) and extending to
the outside with shift-arrow keys, the selection correctly includes the
inset atomically. However, then it is impossible to re-enter the inset
Richard Heck wrote:
> Do you have commit rights still? If so, I'd suggest you go ahead and
> commit to master. Then create the bug and mark it fixedinmaster so we
> can remember to add this to 2.1.x at some point.
I have no idea, my last commit was around 2008 against svn... Should I have
login
Alfredo Braunstein wrote:
> Scott Kostyshak wrote:
>
>> On Tue, Oct 7, 2014 at 10:18 AM, Alfredo Braunstein
>> wrote:
>>> Alfredo Braunstein wrote:
>>>
>>>> Now if the situation is
>>>>
>>>> [one(two|)three]
>>&
Alfredo Braunstein wrote:
> Jean-Marc Lasgouttes wrote:
>
>> Le 07/10/2014 17:21, Alfredo Braunstein a écrit :
>>> Jean-Marc Lasgouttes wrote:
>>>
>>>> Le 07/10/2014 16:18, Alfredo Braunstein a écrit :
>>>>> By the way, this behavior
Jean-Marc Lasgouttes wrote:
> Le 07/10/2014 17:21, Alfredo Braunstein a écrit :
>> Jean-Marc Lasgouttes wrote:
>>
>>> Le 07/10/2014 16:18, Alfredo Braunstein a écrit :
>>>> By the way, this behavior is also a way of triggering
>>>> http://www.lyx
Scott Kostyshak wrote:
> On Tue, Oct 7, 2014 at 10:18 AM, Alfredo Braunstein
> wrote:
>> Alfredo Braunstein wrote:
>>
>>> Now if the situation is
>>>
>>> [one(two|)three]
>>>
>>> then pressing 'End' goes outside of the inse
Jean-Marc Lasgouttes wrote:
> Le 07/10/2014 16:18, Alfredo Braunstein a écrit :
>> By the way, this behavior is also a way of triggering
>> http://www.lyx.org/trac/ticket/3900 ("Mathed corners displayed without
>> mouse hover", now closed/fixed), as when the cur
Alfredo Braunstein wrote:
> Now if the situation is
>
> [one(two|)three]
>
> then pressing 'End' goes outside of the inset:
>
> [one(two)three]|
By the way, this behavior is also a way of triggering
http://www.lyx.org/trac/ticket/3900 ("Mathed corners
Jürgen Spitzmüller wrote:
> 2014-10-06 22:33 GMT+02:00 Alfredo Braunstein:
>
>> I've found out that the attached patch restores my sanity of mind in this
>> particular case. Does anyone has an idea why the request was declared
>> undispatched (after being handled b
Inside a math inset (denoted here by [ ]):
[one(two)t|hree]
( and ) are matched parenthesis (inserted with "Alt-M (") and | is the
cursor. If I press 'End' the cursor goes as expected to the end of the
inset, inside of it:
[one(two)three|]
Now if the situation is
[one(two|)three]
then pres
Pavel Sanda wrote:
> John McCabe-Dansted wrote:
>> 2009/6/16 Pavel Sanda :
>> > ok i just added it. also tried to assimilate to the new directory
>> > structure, please review my patches and send your changes to the code.
>> >
>> > my idea was that "make keystest" should work for devs out of the b
Abdelrazak Younes wrote:
> As I leaked the highly important news that my wife was pregnant
> (whatever JMarc says), I'd thought I should announce formally that this
> state of affair finally led to a small cute little guy named Amir :-)
> The mother (Aya) is doing very well.
[with a little bit of
Abdelrazak Younes wrote:
> Anybody else from neighboring countries? Maybe Italy (Enrico? Alfredo?),
> Netherlands (Edwin?), Czech republic (Pavel?) , etc, etc. Of course
> other countries are kindly invited, aren't they André? José? Lars? Martin?
>
> I hope my geography is correct :-)
Uh tempti
Richard heck wrote:
>
> OK, I understand this bug now. It is, as Abdel suspected, a consequence
> of a problem with InsetTableCell, which I introduced to solve various
> bugs. InsetTableCell holds a pointer to its containing Tabular, so that
> it can get information from it, and that pointer is
Andre Poenitz wrote:
> On Fri, Jun 06, 2008 at 11:12:40PM +0200, Alfredo Braunstein wrote:
>> Jean-Marc Lasgouttes wrote:
>>
>> > "Bennett Helm" <[EMAIL PROTECTED]>
>> > writes:
>> >
>> >> Yes, that indeed works. I'm att
José Matos wrote:
> On Friday 06 June 2008 22:12:40 Alfredo Braunstein wrote:
>> faster than -j2 or was it a typo?
>
> Usually, yes. I use even -j4 on the desktop dual core.
Good to know... I wonder why.
A/
Jean-Marc Lasgouttes wrote:
> "Bennett Helm" <[EMAIL PROTECTED]> writes:
>
>> Yes, that indeed works. I'm attaching the corrected script (now renamed
>> to note that it's explicitly for Mac).
>
> Note that compiling with "make -j3" is much faster on double core
> machines.
faster than -j2 or wa
Pavel Sanda wrote:
> Abdelrazak Younes wrote:
>> No, that means that the workflow has to be rethought a bit. Imagine that
>> you we another frontend
>
> yes, we should support ncurses one day. surely we can't force the terminal
> people using that ugly qt hell forever!
Exactly, who those GUI peo
Abdelrazak Younes wrote:
> Alfredo Braunstein wrote:
>> Jean-Marc Lasgouttes wrote:
>>
>>> Wouldn't it be safer to define a Tabular::operator= and update the
>>> pointers there? Or it is that I do not know what I am talking about?
>>>
>&
Jean-Marc Lasgouttes wrote:
> Wouldn't it be safer to define a Tabular::operator= and update the
> pointers there? Or it is that I do not know what I am talking about?
This would be it. Do I feel more comfortable? Not much, as now one has to
remember to add a member variable to this list (and ho
Jean-Marc Lasgouttes wrote:
>> This seems to fix it. The problem was that a default Tabular::Tabular was
>> called and so InsetTableCell inside CellData inside a new Tabular still
>> pointed to the old Tabular.
>
> Wouldn't it be safer to define a Tabular::operator= and update the
> pointers ther
Alfredo Braunstein wrote:
> File->New
> Insert table, leave 5x5 default
> select it, cut it paste it. enter the table with the cursor -> crash
This seems to fix it. The problem was that a default Tabular::Tabular was
called and so InsetTableCell inside CellData inside a new Tabula
Rex C. Eastbourne wrote:
> Here's a revised version; the graphic designer resized the equations.
>
> http://www.lyx.org/HomeNewGraphic
>
> I agree with JMarc that it would be nice to see how the download button
> looks if it were made glossier, but I felt bad asking the graphic
> designer for mo
Jean-Marc Lasgouttes wrote:
> Alfredo Braunstein <[EMAIL PROTECTED]> writes:
>
>> File->New
>> Insert table, leave 5x5 default
>> select it, cut it paste it. enter the table with the cursor -> crash
>
> You only visit us for bad news, don't you?
Abdelrazak Younes wrote:
> Alfredo Braunstein wrote:
>> Abdelrazak Younes wrote:
>>
>>
>>> That was just a way to say "Welcome back Alfredo!" :-)
>>>
>>
>> Thanks but you know, I never really left, I'm just not doin
Abdelrazak Younes wrote:
> Alfredo Braunstein wrote:
>> File->New
>> Insert table, leave 5x5 default
>> select it, cut it paste it. enter the table with the cursor -> crash
>>
> Why don't you fix it?
Let us call it plan B :-p
> That was just a wa
File->New
Insert table, leave 5x5 default
select it, cut it paste it. enter the table with the cursor -> crash
/usr/include/c++/4.2/debug/vector:205:error: attempt to subscript container
with out-of-bounds index 24, but container only holds 0 elements.
Objects involved in the operation:
sequ
Koji Yokota wrote:
>> if it finds out
>> the expression "^\s*system" or "^\s*\!", it comments out the related
>> lines.
>
> In addition, "load" function must be skipped because its content is not
> known to gnuplot.py. Also, we must consider the case that multiple
> commands exist in one line
It
Andre Poenitz wrote:
> On Wed, Apr 16, 2008 at 12:50:34PM +0200, Abdelrazak Younes wrote:
>> Jean-Marc Lasgouttes wrote:
>>> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>>>
>>>
I receive this each time I send something to the list:
>>>
>>> I asked Mate to remove it and, presto!
Andre Poenitz wrote:
> Which reminds me: Storing Par(Const)Iterators is _not_ safe. They
> are meant to iterate over a non-changing document, nothing else.
>
> At the very least, StableDocIterators have to be used.
StableDocIterators aren't really safer... The only *sort* of 'safe' (i.e.
editio
Andre Poenitz wrote:
> On Mon, Jan 14, 2008 at 12:54:54AM +0100, Alfredo Braunstein wrote:
>> I agree. But note that the point here is that there may be some uses of a
>> real iterator (you can use generic algorithms). Dunno if this is really
>> used in the code though.
>
Abdelrazak Younes wrote:
>> Well it is supposed to be const_iterator semantics... You can get one
>> from a const container, but dereferencing it gives you a const element
>> reference.
>
> I got that but the two iterators don't seem to iterate identically,
> might just be a bad 'tainted' impress
Abdelrazak Younes wrote:
> I fully agree. Up to now I still don't fully grasp the difference
> between ParIterator and ParConstIterator for example. And it took me a
> looong time to understand all the others.
Well it is supposed to be const_iterator semantics... You can get one from a
const cont
Andre Poenitz wrote:
> I am currently poking around in the code and got the feeling that our
> iterators have a tendency of being used wrongly, possibly because parts
> are not really well implemented, and possibly because we don't have
> explanations on what to use when.
>
> The result was e.g.
Andre Poenitz wrote:
> On Wed, Jan 09, 2008 at 09:59:40AM +0100, Alfredo Braunstein wrote:
>> Pavel Sanda wrote:
>>
>> >> Yep, seems perfect, and it should be faster than the other version.
>> >> Note
>> >
>> > unfortunately both st
Pavel Sanda wrote:
>> > unfortunately both std::distance and fun below hangs when counting
>> > inside selection. anybody idea whats going wrong?
>>
>> I think so. If the two ParIterators point to the same paragraph, the loop
>> shouldn't be entered (so there is an off by one error arguably).
>>
Pavel Sanda wrote:
>> Yep, seems perfect, and it should be faster than the other version. Note
>
> unfortunately both std::distance and fun below hangs when counting inside
> selection. anybody idea whats going wrong?
I think so. If the two ParIterators point to the same paragraph, the loop
shou
Pavel Sanda wrote:
>> What about dit.pos() == 0?
>
> hmm. i tried to bake a new function from the hints you gave in wiki,
> does it seem to be right?
Yep, seems perfect, and it should be faster than the other version. Note
that you could use ++dit for shortness. Probably even std::distance(from,
Pavel Sanda wrote:
Hi Pavel,
> chrrm, is there an easy way how to recognize paragraph begining inside the
> loop for (DocIterator dit = from ; dit != to ; dit.forwardPos())
> ?
What about dit.pos() == 0?
A/
Abdelrazak Younes wrote:
> rgheck wrote:
>> Abdelrazak Younes wrote:
>>> Besides, the context menu will be _very_ useful for labels and
>>> citations, trust me ;-)
>>
>> I've got other things to do when I finally get some more LyX-time, but
>> I'd be happy to do what I can to help with this.
>
>
Andre Poenitz wrote:
> So let's wait for a few people to disagree, otherwise we cannot have a
> decent flamewar...
Unfortunately I also agree...
A/
Abdelrazak Younes wrote:
> Dear all,
>
> I think we have enough for a new major release now and I would like us
> to start stabilizing the tree VSN. Considering that last alpha/beta
> period lasted 6 months I think it's time to launch a new alpha. Jose,
> would you like to act as the release mana
Tommaso Cucinotta wrote:
> Andre Poenitz ha scritto:
>> ourselves into a corner here. We had this kind of approach (all
>> paragraph heights known) for a long time and switched to the
>> current one for performance reasons when e.g. loading/resizing
>> inserting in big docments.
>>
> My feeling
Andre Poenitz wrote:
> On Sun, Nov 11, 2007 at 01:21:03PM +0100, Andre Poenitz wrote:
>> > I think this is the time to check it in -- with the trivial
>> > renames you propose. We're not close to a trunk release so any
>> > bugs will get ironed out in a timely manner.
>>
>> I'd like to see some p
Abdelrazak Younes wrote:
>>> If you have serious concerns about this (probably due to the
>>> past experience on developing LyX), the best solution would
>>> be a "summing (balanced) tree", that would exhibit O(log n)
>>> complexity for little updates like needed in 1) [not sure about
>>> 1.a], bu
Andre Poenitz wrote:
>> 1) change of height of currently edited par
>> 1.a) break of currently edited par (Enter)
>> 2) cut and paste operations
>> 3) width resize of screen
>
> 4) Loading of a document.
>
>> If you have serious concerns about this (probably due to the
>> past experience on de
Abdelrazak Younes wrote:
>> please do you think i'm worthy enough to gain commit access ?
>> is not the only pending patch from me which is obsolete now just because
>> nobody has time to commit it.
>
> I've warned about this bad situation many times. And this is not
> affecting only you.
>
> In
Andre Poenitz wrote:
> So instead of 12 lines of straightforward code we use of 26 lines of
> ridiculously complex code that _needs to explained_(!) in 9 more lines.
>
> Moreover, this completely unnecessary use of ,
> and adds 172725 lines to a full compilation
> of LyX.
>
> That's exactly t
Pavel Sanda wrote:
> well for the basic checks i usually see in Andre's syntax warnings we
> really dont need any third party code. few lines of greping will do. as my
> python skills are very limited i can write some set of tests in bash, but
> that will unusable for ms folks.
Why bother with sc
Andre Poenitz wrote:
>> That might be enough. But it's not clear to me if this causes problems
>> with cut and paste.
>
> Sure there will problems, but right now we already have special handling
> for e.g. and three hundred inset function or so taking a buffer
And what's the real problem with th
Andre Poenitz wrote:
> Call a 'register' function from a constructor of a static dummy object.
> This is sometimes troublesome with shared objects/older compiler,
> though.
>
> In any case, it wouln't help with the typos (Compati_a_ble(
For these problems I'd recommend using the other static dum
Jean-Marc Lasgouttes wrote:
> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>
>> Right now Buffer edition is blocked up until LateX compilation is
>> finished. This situation is not mandatory and we could as well
>> "detach" the process and let the Buffer edition continue for the user
>> (Peter's
Angus Leeming wrote:
> Abdelrazak Younes wrote:
>> PS: Sorry Angus but you deserved it ;-)
>> PPS: I'm talking about Rugby...
>
> Me too. So did you.
:-)
A/
Abdelrazak Younes wrote:
> Hum not so good as we are both wrong!
> We should not count the .svn/ directory... images/math/ is actually 2.9M.
Haha you're right.
>>> Another thing that makes me wonder, the 1.5.x lib/images dir with .xpm
>>> images was only 2.9M. Did the xpm -> png change had some
Abdelrazak Younes wrote:
> Good question.
>
>> Because in the
>> second case the change could actually mean *slower* startup times...
>
> I don't think the difference would be noticeable... the lib/images/math
Didn't this start as a presumable startup time improvement?
> directory is only 6 me
Abdelrazak Younes wrote:
>> And this is an advantage because?
>
> Presumably faster loading. I haven't tested yet but I can imagine that
> reading one big file on disk is faster than reading 600 small files
> (this is for sure on Windows). Note that most of the icons are loaded on
> startup now t
Andre Poenitz wrote:
> On Thu, Oct 18, 2007 at 12:20:23PM -0500, Bo Peng wrote:
>> > This is a generated file built by
>> >
>> > Resources.qrc:
>> > echo "" > $@
>> > find $(top_srcdir)/lib/images -name '*.png' \
>> > | sed -e 's:$(top_srcdir)/lib/\(.*\):> >
Andre Poenitz wrote:
>> > Writing the emergency file is only part of what I want. I also want to
>> > present the user with a dialog telling him about the error and giving
>> > him the option to continue at his own risk.
>> >
>> > There is absolutely no reason to abort if i.e. s&r or loading of a
1 - 100 of 2238 matches
Mail list logo
