Scott Kostyshak wrote:
> This is what I was suggesting (and is implemented in the patch). It is
> clearly not popular though.
You really find this useful? Single hit of end key bring me to the end while
there is no comparable jump back to original row in case I hit down arrow more
times than actua
On Wed, Jun 19, 2013 at 10:52 PM, Pavel Sanda wrote:
> Jean-Marc Lasgouttes wrote:
>> [Side note: if during your research you find some function with a
>> lacking/wrong documentation, fel free to submit a patch to improve it.]
>
> Hashini, improving our lacking documentation of source code by what
I actually don't mind that much if the behavior changes. It may be nice to
have a setting for this, though (even though most users will not change the
default).
Scott Kostyshak wrote:
On Wed, Jun 19, 2013 at 3:55 PM, Pavel Sanda wrote:
Should we do begining-of-line when in the first lien to
Jean-Marc Lasgouttes wrote:
> [Side note: if during your research you find some function with a
> lacking/wrong documentation, fel free to submit a patch to improve it.]
Hashini, improving our lacking documentation of source code by whatsover
you learn through threads like this would be real gai
On Wed, Jun 19, 2013 at 3:55 PM, Pavel Sanda wrote:
> Should we do begining-of-line when in the first lien to be consistent as well?
This is what I was suggesting (and is implemented in the patch). It is
clearly not popular though.
Scott
Hi Scott,
I think an annual survey is too slow and does not help if a patch is ready
and the next survey is 11 months away.
I think a few questions (like yours below) sent to the lyx-users and/or
lyx-devel mailing lists will do the job well. Those users who are
interested in answering the que
Kornel Benko wrote:
> being consistent, that is). ;)
Consistent with what?
I just tried OpenOffice and M$ Word, both are consistent not to do it by
default.
(None terminal editors I use do this by default, but that's not fair comparison
in similar way as gmail is not co be counted ;)
Should we d
This is what I call a real democracy, so good news from LyX developers. Now
my 2c (personal opinion, not necesarily ok)
(A1) continuous spell-check by default.
I don´t like this, I first write and then spell check the entire document.
(A2) behavior of LFUN_DOWN_SELECT on last line.
If you
On Tue, Jun 18, 2013 at 3:43 AM, Kornel Benko wrote:
> Am Montag, 17. Juni 2013 um 23:02:48, schrieb Pavel Sanda
>
>> Scott Kostyshak wrote:
>
>> > It looks like this might be a personal preference.
>
>>
>
>> Most probably ;)
>
>
>
> +1
Good to know. Thanks for the confirmation.
Scott
LyX users influence development by posting tickets on trac. A few
brave users participate in discussions on lyx-devel. I think there is
a clear way for LyX users who would like to get in touch with LyX
developers. I think the other way is less obvious.
I often find myself thinking "I wonder what m
On 06/19/2013 09:33 AM, Hashini Senaratne wrote:
The code that draws the cursor does not know that you have moved the
row, so I aimgaine it will be wrong. What I would do maybe is to add a
x_offset (or something) variable to the Cursor object that indicates
that the row is sliding. Then the curso
19/06/2013 15:33, Hashini Senaratne:
The code that draws the cursor does not know that you have moved the
row, so I aimgaine it will be wrong. What I would do maybe is to add a
x_offset (or something) variable to the Cursor object that indicates
that the row is sliding. Then the cursor-blink code
> The code that draws the cursor does not know that you have moved the
> row, so I aimgaine it will be wrong. What I would do maybe is to add a
> x_offset (or something) variable to the Cursor object that indicates
> that the row is sliding. Then the cursor-blink code could take this in
> accou
19/06/2013 15:11, Hashini Senaratne:
Above problem was able to solve with the use of cur.targetX() and
bv.workWidth() as follows. Now the whole page slides as expected if we move
the cursor along a too wide Math inset. But the cursor gets disappear after
passing the right edge of the screen.
I tr
Hello Jean-Marc,
> I tested what you have given and that helped me to understand more. Today I
> did more testing and realized that cur.pos() is not related with pixels and
> this approach cannot be used as a generic solution.
>
> Problems:
> *I checked the cur.pos() values inside a tabular inse
19/06/2013 13:07, Hashini Senaratne:
I tested what you have given and that helped me to understand more. Today I
did more testing and realized that cur.pos() is not related with pixels and
this approach cannot be used as a generic solution.
Cur.pos() counts the characters. For example cur.pos()
Hello Jean-Marc,
> You have to check that you are in the correct paragraph. pos is the
> position in the paragraph. The index of the paragraph is "pit" (the same
> that is passed to RowPainter constructor). Thus the test should be
>
> if (cur.pos() >0 && cur.pit() == pit)
>
> This will however
17 matches
Mail list logo
