On Thu, Mar 11, 2004 at 08:52:24PM +0100, Alfredo Braunstein wrote:
> Of course, the question is *when uncollapsed*. I cannot draw it uncollapsed
> with ascii-art because I don't know how it will rebreak (exactly the
> question). My question is (third time) how does your ideal_width works... So
>
On Thu, Mar 11, 2004 at 07:30:23PM +, Angus Leeming wrote:
> Sure, but this visual info need not be the width of the area into
> which you're typing the text. It could be a horizontal arrow with the
> actual width as text. Eg:
>
> <-- Width 1 in -->
> -
Sure, why not, but
John Levon wrote:
>> >> blah blah blah [I] blah
>> >> blah blah blah blah blah bla
>> >
>> > I don't understand your example. Row breaking is done in left-to-right,
>> > top-to-bottom manner, how could the above ever have an unknown width ?
>>
>> Well soppose [I] is an inset full of text (i
John Levon wrote:
>> > Minipages. If I set two minipages to 50% it would be nice if they
>> > appeared next to each other, like they used to. That's all.
>>
>> Didn't knew that (never used that myself). I don't know if I would
>> like it though - that too much wysiwyg at the cost of clutter
>> edi
On Thu, Mar 11, 2004 at 07:50:21PM +0100, Alfredo Braunstein wrote:
> > Minipages. If I set two minipages to 50% it would be nice if they
> > appeared next to each other, like they used to. That's all.
>
> Didn't knew that (never used that myself). I don't know if I would like it
> though - that
John Levon wrote:
> Minipages. If I set two minipages to 50% it would be nice if they
> appeared next to each other, like they used to. That's all.
Didn't knew that (never used that myself). I don't know if I would like it
though - that too much wysiwyg at the cost of clutter editing.
> Colour
This is new:
lyx --export pdf commit.lyx
Assertion triggered in BufferView* LyXText::bv() const by failing check "bv_owner !=
0" in file text.C:171
--
Kayvan A. Sylvan | Proud husband of | Father to my kids:
Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (
On Thu, Mar 11, 2004 at 11:40:39AM +, Angus Leeming wrote:
> Given that everything is an inset, why don't we have an "indent" inset
> and insert this as the first character in a paragraph? That would
> remove all this special casing from the core.
It would be lovely and of course several of
On Thu, Mar 11, 2004 at 09:41:13AM +0100, Alfredo Braunstein wrote:
> I mean, I'm sure you know it's not the only open bug in current cvs.
He he :)
(never ashamed to overuse emoticons myself!)
> > o how wide is the box
> > o what width does a char want (for full width insets: 100%, for
> > mi
just cvsed up and loaded the userguide:
1) cursor starts in some strange position. going back gives a crash
2) The Edit menu gives a crash
Alfredo
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
Jean-Marc> The following patch allows to create textclass.lst in the
Jean-Marc> case where latex is not present or --without-latex-config
Jean-Marc> has been passed to lib/configure. It adds all the claases
Jean-Marc> it finds,
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Thu, Mar 11, 2004 at 12:21:05PM +0100, Lars Gullik Bjønnes wrote:
>> Andre Poenitz <[EMAIL PROTECTED]> writes:
>>
>> | When I think about it: Has anybody ever tried to use a std::vector<>
>> | (-like container) instead of a std::list<> as text contai
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Thu, Mar 11, 2004 at 12:16:49PM +0100, Lars Gullik Bjønnes wrote:
>> | + // Now the real work
>> |string mname = os::slashify_path(name_);
>> |// Remove the extension.
>> |mname = ChangeExtension(name_, string());
>> | @@ -73,7 +85,15 @@
Andre Poenitz wrote:
> - replace the LyXText member in the Buffer pimpl by an InsetText.
> This means we can drop a lot of special casing for the access
> to the toplevel text as in
This seems a great move.
> [- rename BufferView::buffer to BufferView::setBuffer. Better for 'grep'.]
>
> [
Angus Leeming wrote:
>> The only real problem I see with the current implementation is the
>> inset placement in the first position of the first indented line of
>> a paragraph. It is probably easy IMHO to find a quick solution for
>> that without changing the overall scheme...
>
> Given that eve
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Given that everything is an inset, why don't we have an
Angus> "indent" inset and insert this as the first character in a
Angus> paragraph? That would remove all this special casing from the
Angus> core.
Angus> Guess we'd also need
On Thu, Mar 11, 2004 at 11:40:39AM +, Angus Leeming wrote:
> > The only real problem I see with the current implementation is the
> > inset placement in the first position of the first indented line of
> > a paragraph. It is probably easy IMHO to find a quick solution for
> > that without chang
On Thu, Mar 11, 2004 at 12:21:05PM +0100, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | When I think about it: Has anybody ever tried to use a std::vector<>
> | (-like container) instead of a std::list<> as text container?
>
> You loose the fast undo/paste stuff. si
On Thu, Mar 11, 2004 at 12:16:49PM +0100, Lars Gullik Bjønnes wrote:
> | + // Now the real work
> | string mname = os::slashify_path(name_);
> | // Remove the extension.
> | mname = ChangeExtension(name_, string());
> | @@ -73,7 +85,15 @@
> | // Replace '.' in the file name with '
Georg Baum wrote:
> Here it is (without the '#' in the filename). I tested it, and it
> works even for multiply-included files.
> If this is ok, could somebody please apply? I really hope I can go
> on with the fixes I actually wantend to do without discovering
> further problems.
Georg, I committ
Alfredo Braunstein wrote:
> Why would anyone want to waste the 75% of the screen!?? I think it's
> really silly to represent %col in a wysiwyg way. Then full row
> insets are already represented by the display() bool.
Hear! Hear!
> The only real problem I see with the current implementation is t
Andre Poenitz <[EMAIL PROTECTED]> writes:
| When I think about it: Has anybody ever tried to use a std::vector<>
| (-like container) instead of a std::list<> as text container?
You loose the fast undo/paste stuff. since you will need to
reallocate... with std::list a splice is done.
What are the
Georg Baum <[EMAIL PROTECTED]> writes:
| string const FileName::mangledFilename() const
| {
| + // We need to make sure that every FileName instance for a given
| + // filename returns the same mangled name.
| + static map mangledNames;
| + map::const_iterator const it = mangledN
On Thu, Mar 11, 2004 at 11:38:16AM +0100, Alfredo Braunstein wrote:
> > (1) A 'stable' iterator not dependent on the location of some random
> > chunk in memory (aka 'pointer'). Ok, that was already defeated by having
> > the inset_ cache, but my original intention wsa to get rid of that.
>
> Why
Andre Poenitz wrote:
> No, both have to be kept in sync. This should be O(1) though for
> standard operations like initialization, one up, one down etc.
>
>> Doesn't that defeat the purpose of having the offset at all
>
> Partially, yes.
>
>> (hum... what was it again)?
>
> (1) A 'stable' iter
On Wed, Mar 10, 2004 at 01:22:32PM +0100, Alfredo Braunstein wrote:
> the font is not set when navigating with cursor up/down.
>
> This seems to cure it.
Good.
[The font stuff is still a bit of a mess. We need to get rid of this
'outerPar' business somehow. I'd think passing a DocumentIterator
i
On Wed, Mar 10, 2004 at 09:05:40AM +0100, Alfredo Braunstein wrote:
> > The obvious idea is to use and/or cache some ParagraphList iterator
> > instead of the par offset...
> >
> > Maybe we've to use both. In fact, it's almost the same as with the
> > 'inset_' member: This is just a form of a cach
John Levon wrote:
> Not sure it's random, given the nubmer of times it's been discussed.
I mean, I'm sure you know it's not the only open bug in current cvs.
(emoticon elided)
> If you missed out the long discussions, then sorry, I had assumed they
> were somewhat unavoidable.
I've probably ign
28 matches
Mail list logo
