> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
I applied it.
JMarc
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Jean-Marc Lasgouttes wrote: why not + cur.lastpos() !=
Angus> (cur.pos() + 1) && ?
>> Oops. I am not even sure that the test meant what I thought it
>> meant.
>>
>> What about the following?
Angus> Isn't that semantically the sam
Jean-Marc Lasgouttes wrote:
> Angus> why not + cur.lastpos() != (cur.pos() + 1) && ?
>
> Oops. I am not even sure that the test meant what I thought it meant.
>
> What about the following?
Isn't that semantically the same as:
@@ -1020,7 +1021,8 @@ bool LyXText::cursorRight(LCursor & cur)
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> why not + cur.lastpos() != (cur.pos() + 1) && ?
Oops. I am not even sure that the test meant what I thought it meant.
What about the following?
JMarc
Index: src/ChangeLog
=
Jean-Marc Lasgouttes wrote:
> The following patch fixes bug 2010:
> http://bugzilla.lyx.org/show_bug.cgi?id=2010
>
> This was an unintended consequence of the work Juergen V. did to allow
> placing the cursor in front of a displayed inset.
>
> Please test.
>
> JMarc
why not
+ cur.lastpos() !
The following patch fixes bug 2010:
http://bugzilla.lyx.org/show_bug.cgi?id=2010
This was an unintended consequence of the work Juergen V. did to allow
placing the cursor in front of a displayed inset.
Please test.
JMarc
Index: src/ChangeLog
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> This, in turn, implies that the visual dots have to be fairly
Asger> intrusive in the interface.
Asger> How does Emacs (or any other editor) handle this direction
Asger> problem?
Does word handle it?
Asger> LyX should
Duncan Simpson <[EMAIL PROTECTED]> writes:
| gcc 2.96 has trouble with the test inset too. I am sure this is a bug but not
| sure what the correct fix actually is, as ignoring const is not nescarily
| safe. Could someone who knows the coed better determine whether a cast,
| prototype twiddle o
> "Amir" == Amir Karger <[EMAIL PROTECTED]> writes:
Amir> ALternatively, you could change the cursor depending on the
Amir> direction.
I thought it was already the case.
JMarc
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
>> Spacing between paragraphs as defined by
>> Layout->Paragraph. An following a This will
>> always put more space in LyX, but depending on where the cursor is
>> it may or may not put more space in the printed version. There are
>> also c
gcc 2.96 has trouble with the test inset too. I am sure this is a bug but not
sure what the correct fix actually is, as ignoring const is not nescarily
safe. Could someone who knows the coed better determine whether a cast,
prototype twiddle or massive code change is appropiate here?
make[3]
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
Allan> On Sat, 22 Apr 2000, Garst R. Reese wrote:
>> "Asger K. Alstrup Nielsen" wrote: > > > My feeling at this point is
>> that the dots are justified to solve the > direction problem, but I
>> still think they are too intrusive to solve > t
FWIW, as someone who's not contributing to lyx at all right now, let me come
down on the side of opposing red dots except when absolutely necessary.
Each thing you add to LyX makes it that much more confusing for new users,
in addition to becoming more cluttered for experienced users.
For languag
On Mon, 24 Apr 2000, Garst R. Reese wrote:
> Allan Rae wrote:
>
> > > Could the direction problem be solved with left and right mouse button
> > > clicks? Possibly two clicks, one to position the mouse, the second to
> > > set direction.
> >
> > The right mouse will eventually be used for conte
Allan Rae wrote:
> > Could the direction problem be solved with left and right mouse button
> > clicks? Possibly two clicks, one to position the mouse, the second to
> > set direction.
>
> The right mouse will eventually be used for context sensitive menues --
> although I suppose a click could
On Sat, 22 Apr 2000, Garst R. Reese wrote:
> "Asger K. Alstrup Nielsen" wrote:
> >
> >
> > My feeling at this point is that the dots are justified to solve the
> > direction problem, but I still think they are too intrusive to solve
> > the language, and font, problems.
Personally, I think the
"Asger K. Alstrup Nielsen" wrote:
>
>
> My feeling at this point is that the dots are justified to solve the
> direction problem, but I still think they are too intrusive to solve
> the language, and font, problems.
> For the latter part, we should try to solve the problems by providing
> more i
> The main reason that I want this change ("the red dot") is for the RTL support:
I recognize that there is a problem here, because the cursor has to
have direction as well as position. When you use the mouse, you only
specify position, and therefore the direction is unspecified at the
borders. L
On Thu, Apr 20, 2000 at 11:58:27AM +0200, Asger K. Alstrup Nielsen wrote:
> [Change of font data structure to be a sorted list and use special characters
> to represent font change points]
>
> Also, I have a feeling that it's the wrong approach. What problem are you
> *really* trying to solve?
> [Change of font data structure to be a sorted list and use special characters
> to represent font change points]
More discussion:
The change will increase memory consumption, although only minimally.
Regarding the argument that it will be possible to get the proper font
change by being able t
> I've looked for your kernel in the 'lyx' cvs module, but the code there is
> incomplete. Is there a working version of your kernel? Is it still the plan
> to use it instead of the current kernel? When?
The kernel in the cvs module is what there is, besides some documentation
which I'm not sure
Angus Leeming <[EMAIL PROTECTED]> writes:
| Well I use them all the time in the math editor to show me whether I'm inside
| or outside a macro --- at least I have to bound my macro with ERT {} and would
| much prefer it if I could get this info from a special char.
This is not what I put into sp
Dekel Tsur <[EMAIL PROTECTED]> writes:
| > (I realy don't like the special chars)
|
| Why?
Becasue they are in the 256 char namespace...
| I've already implemented the first point. Should I submit it now, or after
| 1.1.5 ?
Regardless of what we do it should be done after 1.1.5.
Lgb
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> Are you serious? Dekel's approach sounds *much* cleaner and if
Andre> you don't render the red dots there should be no visible change
Andre> at all.
You can have red dots without special character. And if you hide the
special char
> Well I guess that this may be resolved much better when using the
> direction where the cursor came from. So when entering from left we should
> use bold otherwise we could use normal.
And some day LyX's behaviour does not just depend on the position of the
cursor and the direction it was comin
Dekel> Furthermore, the use of special char is also for the purpose of
Dekel> differentiating the position before the font change and after the font change:
Dekel> Suppose you have a word "abcd" where ab is in the default font, and cd is in
Dekel> bold. Now, what happens when you place the cursor
On 19-Apr-2000 Dekel Tsur wrote:
>
> Furthermore, the use of special char is also for the purpose of
> differentiating the position before the font change and after the font change:
> Suppose you have a word "abcd" where ab is in the default font, and cd is in
> bold. Now, what happens when you
> 1. The paragraph stores a vector (FontList) of pairs (position, font),
> sorted by positions, containing the positions in the paragraph in which the font
> changes, and the corresponding fonts.
You don't even need the position. The information is implicitly contained
in the rest of the structur
On Wed, Apr 19, 2000 at 12:52:46PM +0200, Lars Gullik Bj&resh;nnes wrote:
> Dekel Tsur <[EMAIL PROTECTED]> writes:
>
> | For the current kernel, I thought of the following changes to the
> | way the fonts
> | are stored by the LyX paragraph class:
> |
> | 1. The paragraph stores a vector (FontL
Dekel Tsur <[EMAIL PROTECTED]> writes:
| I've looked for your kernel in the 'lyx' cvs module, but the code there is
| incomplete. Is there a working version of your kernel? Is it still the plan
| to use it instead of the current kernel? When?
We jumped the gun a bit when we put the "new kernel"
> I think this is a bad idea for performance reasons. Notice that it's
> not only memory issues: It's also the issue of displaying on screen.
> Displaying on screen is the most important bottleneck, and it has to
> be fast. It will not be fast if the fundamental data structure is
> one character a
On Fri, Apr 14, 2000 at 10:29:14AM +0200, Jean-Marc Lasgouttes wrote:
> > "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes:
>
> Dekel> Hebrew is written from Right to Left. However, numbers are
> Dekel> written from Left to Right, so if you type "abc 123 def" [a..f
> Dekel> are Hebrew letters
On Fri, Apr 14, 2000 at 09:18:21AM +0200, Juergen Vigna wrote:
>
> Do you remove the number-inset stuff or should I do it for you, as it
> seems this is not needed anymore and we should remove dead code!
>
If you insist...
(but don't remove the auto_number variable in lyxrc)
On Fri, Apr 14, 2000 at 11:35:33AM +1000, Allan Rae wrote:
> On Thu, 13 Apr 2000, Dekel Tsur wrote:
>
> > (since in the latex output, a number should be enclosed by \beginL .. \endL).
> > With my approach, this is not needed (the \beginL .. \endL are generated by
> > LyXFont::latexWriteStartChang
> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes:
Dekel> Hebrew is written from Right to Left. However, numbers are
Dekel> written from Left to Right, so if you type "abc 123 def" [a..f
Dekel> are Hebrew letters] then the display should be "fed 123 cba".
Why not use directly a formula inse
Dekel Tsur <[EMAIL PROTECTED]> writes:
| I've already explained it before, but here is a more detailed overview of
| the number problem:
[nice explanation snipped]
I still just think this is a special case of the "CharParams"
attribute that we want to be able to have on words, sentences, chars.
On 13-Apr-2000 Dekel Tsur wrote:
[sniped good explanation]
>
> 3. I think that it is easier to implement in LyX.
> Implementing the automatic approach requires doing changes in
> LyXParagraph::SimpleTeXOnePar, and LyXParagraph::SimpleTeXOneTablePar
> (since in the latex output, a number should b
On Thu, 13 Apr 2000, Dekel Tsur wrote:
> (since in the latex output, a number should be enclosed by \beginL .. \endL).
> With my approach, this is not needed (the \beginL .. \endL are generated by
> LyXFont::latexWriteStartChanges & LyXFont::latexWriteEndChanges).
Isn't this the same as switchin
> Hi Dekel!
>
> What I don't understand (and we already asked you ;) is why you need a
> special number atribute. Shouldn't this non be automatic in the display
> mechanism? So why do you need the attribute numbers are [0-9] that's
> easy (but probably you want something else I just cannot see it
> I haven't been watching closely this discussion, so I want to ask about the
> "number attribute" I want to add (for markup of numbers in Right-to-Left text).
> Should I implement it (for now) by adding a new field to the LyXFont class?
> (actually, I've already done this, so if this is the "corr
On 10-Apr-2000 Dekel Tsur wrote:
> On Mon, Apr 10, 2000 at 09:45:01PM +0200, Asger K. Alstrup Nielsen wrote:
>> > > Thank you for the taking you time to answer this. :)
>> >
>> > I have to, in order to avoid you guys reinventing the wheel.
>>
>> I forgot to argue why we should adopt the charact
On Mon, Apr 10, 2000 at 09:45:01PM +0200, Asger K. Alstrup Nielsen wrote:
> > > Thank you for the taking you time to answer this. :)
> >
> > I have to, in order to avoid you guys reinventing the wheel.
>
> I forgot to argue why we should adopt the character attribute
> approach *now* for all kin
> > Thank you for the taking you time to answer this. :)
>
> I have to, in order to avoid you guys reinventing the wheel.
I forgot to argue why we should adopt the character attribute
approach *now* for all kinds of attributes: Since the future kernel
uses this approach, we will be much better
> I'm aware of the difference between attribute and elements (tags).
> And I know this represents different ways to deal with specialization.
>
> I don't think there a prefered way, it is always a matter of compromisse.
> Something like templates vs class hierarchy.
Yes.
> One question before p
On Mon, Apr 10, 2000 at 04:36:04PM +0200, Asger K. Alstrup Nielsen wrote:
> I can appreciate why you ponder this issue, because it's only natural to extend
> the SGML model to the LyX document structure. In HTML, such attributes are often
> modelled as a tag. Consider and . Granted, those nest, s
> It was my mistake here, not to make the meaning of word clear in the context.
> Second attempt, is this clear now? ;)
Yes.
> > I think it's more important to recognize the similarity with font attributes,
> > just like HTML does with the property, and thus reduce complexity.
>
> In the
On Sun, Apr 09, 2000 at 12:32:51PM +0200, Asger K. Alstrup Nielsen wrote:
> > Clear now?
>
> No, it's not clear why we should spent energy to impose such a restriction?
I guess so. :)
When I first refer to word, I was refering to a set of chars, where a blank is
allowed.
I was placing
> Maybe I wasn't clear (that isn't difficult ;) I am not against the char resolution
> attributes, I simply think that we should have middle range attributes that are
> perhaps best descrived as insets. And logical structures as Contry or Name should
> be one of those cases.
>
> Clear now?
N
On Tue, Apr 04, 2000 at 02:41:40AM +0200, Lars Gullik Bj&resh;nnes wrote:
> Allan Rae <[EMAIL PROTECTED]> writes:
>
> | This number business is just a rtl-ltr language switch that Dekel wants
> | automatically handled.
>
> This is not quite how I understood it. To me it seemd like an
> additiona
On Sat, Apr 08, 2000 at 10:44:56AM +0200, Asger K. Alstrup Nielsen wrote:
> [Properties of individual characters or words]
> > After some reflection I think that contry is a bad example, most of the
> > regular logical attributes should be word related and thus some sort of (simple)
> > inset, a
[Properties of individual characters or words]
> After some reflection I think that contry is a bad example, most of the
> regular logical attributes should be word related and thus some sort of (simple)
> inset, and not font related.
>
> Will this simplify the underlying architecture?
I can
On Fri, Apr 07, 2000 at 06:16:55PM +0200, Lars Gullik Bjønnes wrote:
> Jose Abilio Oliveira Matos <[EMAIL PROTECTED]> writes:
>
> | > I am fiddling with the thought of having a TextAttributes where we now
> | > have LyXFont. This TA would normally just contain a regualar LyXFont,
> | > but in oth
Jose Abilio Oliveira Matos <[EMAIL PROTECTED]> writes:
| > I am fiddling with the thought of having a TextAttributes where we now
| > have LyXFont. This TA would normally just contain a regualar LyXFont,
| > but in other cases it would hold a logical attribute f.ex. "Country".
| > This attribte w
On Tue, Apr 04, 2000 at 02:15:54AM +0200, Lars Gullik Bjønnes wrote:
> I plain hate meantimes, they hamper development and tends to build up
> until they are almost impossible to get rid of when the time
> eventually comes to do it proper.
Agreed.
> I am fiddling with the thought of having a
Allan Rae <[EMAIL PROTECTED]> writes:
| This number business is just a rtl-ltr language switch that Dekel wants
| automatically handled.
This is not quite how I understood it. To me it seemd like an
additional font attribute that said that "this is a number", then the
needed machinery to output
On 4 Apr 2000, Lars Gullik Bjønnes wrote:
> Dekel Tsur <[EMAIL PROTECTED]> writes:
>
> | On Tue, Apr 04, 2000 at 12:42:05AM +0200, Lars Gullik Bjønnes wrote:
> | >
> | > We really don't want to put to many features into LyXFont. If I
> | > understand you correctly you want to mark the string "1
Dekel Tsur <[EMAIL PROTECTED]> writes:
| On Tue, Apr 04, 2000 at 12:42:05AM +0200, Lars Gullik Bjønnes wrote:
| >
| > We really don't want to put to many features into LyXFont. If I
| > understand you correctly you want to mark the string "123" to be a
| > number and appropriate action taken whe
On Tue, Apr 04, 2000 at 12:42:05AM +0200, Lars Gullik Bj&resh;nnes wrote:
>
> We really don't want to put to many features into LyXFont. If I
> understand you correctly you want to mark the string "123" to be a
> number and appropriate action taken when exporting/printing etc.
>
> To me this see
Dekel Tsur <[EMAIL PROTECTED]> writes:
| There are two problems with numbers in Hebrew:
| 1. In the LaTeX output, the number should be enclosed by \beginL / \endL
| (e.g., \beginL 123 \endL).
| 2. While writing the text, you should not press a special key for telling the
| editor when you are sta
On Mon, Apr 03, 2000 at 10:07:05AM +0200, Juergen Vigna wrote:
> On 01-Apr-2000 Dekel Tsur wrote:
> > I'm considering of adding a new inset (InsetNumber) for the purpose of
> > entering numbers in Right-To-Left text: when you press a digit key, instead
> > of inserting the digit into the current p
> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes:
Dekel> 2. Is it in a usable state? (if not, I can make the InsetNumber
Dekel> a derived class of InsetFormula).
Note that, in TeX, numbers are supposed to be typeset in formulas
(almost) always. Of course, there are always cases where you w
it is inserted to the inset.
>
I really don't see the advantage of such an inset? Could you enlighten me?
> I've implemented this inset as a derived class of InsetText. In this process,
> I've encountered several bugs in InsetText. Before I list them, I want to
> ask g
inset as a derived class of InsetText. In this process,
I've encountered several bugs in InsetText. Before I list them, I want to
ask general question about the text inset:
1. What is its purpose? Is it supposed to replace the LyXText class?
2. Is it in a usable state? (if not, I can make th
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
Juergen> On 08-Mar-2000 Jean-Marc Lasgouttes wrote:
>> Is that really a good thing?
>>
Juergen> Well it does not have ANY space-handling yet :)
Juergen> I would say that it depends on the type of inset if we have
Juergen> spacehandl
On 08-Mar-2000 Jean-Marc Lasgouttes wrote:
>
> Is that really a good thing?
>
Well it does not have ANY space-handling yet :)
I would say that it depends on the type of inset if we have spacehandling
ore not. IMO that the ERT inset should not have any space-handling as this
is LaTeX code and
Is that really a good thing?
JMarc
66 matches
Mail list logo
