Le 20/07/2017 à 15:13, Jürgen Spitzmüller a écrit :
Am Donnerstag, den 20.07.2017, 14:57 +0200 schrieb Jean-Marc
Lasgouttes:
Technically, insets with a dialog are also "editable".
No, now we say that they "have settings". The notion of editable is
really related to enteri
Am Donnerstag, den 20.07.2017, 14:57 +0200 schrieb Jean-Marc
Lasgouttes:
> > Technically, insets with a dialog are also "editable".
>
> No, now we say that they "have settings". The notion of editable is
> really related to entering in the inset with a cursor.
comments, shouldn't it be something like:
cursorCanEnter() (editable())
Well technically cursor can enter a closed InsetCollapsable (with
find)
Technically, insets with a dialog are also "editable".
No, now we say that they "have settings". The notion of editable is
real
ents, shouldn't it be something like:
> >
> > cursorCanEnter() (editable())
>
> Well technically cursor can enter a closed InsetCollapsable (with
> find)
Technically, insets with a dialog are also "editable".
>
> It is a pity that cursorable does
Le 20/07/2017 à 11:52, Jürgen Spitzmüller a écrit :
Am Donnerstag, den 20.07.2017, 11:38 +0200 schrieb Jean-Marc
Lasgouttes:
Sigh. It turns out I understood the whole isActive/editable/nargs
issue
only vaguely.
The reason probably is that the naming of these functions is not really
good
Le 20/07/2017 à 11:52, Jürgen Spitzmüller a écrit :
The reason probably is that the naming of these functions is not really
good.
Indeed.
As I understand your comments, shouldn't it be something like:
cursorCanEnter() (editable())
Well technically cursor can enter a c
Am Donnerstag, den 20.07.2017, 11:38 +0200 schrieb Jean-Marc
Lasgouttes:
> Sigh. It turns out I understood the whole isActive/editable/nargs
> issue
> only vaguely.
The reason probably is that the naming of these functions is not really
good.
As I understand your comments, should
t;find".
Actual: LyX places the cursor before the inset and leaves the inset
closed.
Sigh. It turns out I understood the whole isActive/editable/nargs issue
only vaguely.
I fixed this in master now at fc7fb6a56 and tried to document what the
functions actually do. I have to backport this to
On Tue, Jun 27, 2017 at 04:47:10PM +0200, Jean-Marc Lasgouttes wrote:
> commit 13c3c1485b68980c51658cef8fadf804982d75ee
> Author: Jean-Marc Lasgouttes
> Date: Fri Jun 23 20:32:32 2017 +0200
>
> Fixup the fixup d0acc3e57044: use editable()/isActive()
>
> W
Guillaume,
What do you think of this one instead? I don't want to commit it and fix
it up a third time :)
I think that it is consistent with your comments :) sorry I do not have
anything further useful to say about it. I agree that it would be good
to see if isActive and editable could be m
x27;t want to commit it and fix
it up a third time :)
JMarc
>From 3d2fc98046c086fe89b2e431166de60cb3561148 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes
Date: Fri, 23 Jun 2017 20:32:32 +0200
Subject: [PATCH] Fixup the fixup d0acc3e57044: use editable()/isActive()
While 522516d9 was to
merging of
editable() and isActive(), but I'd rather not do it right now.
The current code in 2.2 will miss some cases where a cursor slice will
not be choped while it should be. I will propose a uglier but more
correct version.
JMarc
d0acc3e570447b293169b8bdd5ac67aaade189e0
Author: Jean-Marc Lasgouttes
Date: Tue Jun 20 09:41:48 2017 +0200
Fixup 522516d9 : editable() is unusable in mathed
This is a relic from IU (Inset Unification): editable() is for text
insets and isActive() for mathed. This needs to be cleaned up.
Part of
Le 23/03/2015 20:17, Richard Heck a écrit :
For now, I pushed a fix at c2f785bdc. Richard, I will have to backport
it to branch, since the faulty commit is ported at d5eeabcfd.
OK.
Done.
JMarc
DocIterator::sanitize only adds editable insets
This fixes the crash on ticket #9432, but the bug there has
other causes.
This causes a new crash for me:
1. start a new LyX document
2. alt+m f to create a fraction
3. alt+m r to insert a root
4. undo
Indeed :( It turns out that editable
On Mon, Mar 23, 2015 at 2:55 PM, Jean-Marc Lasgouttes
wrote:
> Le 23/03/2015 19:45, Kornel Benko a écrit :
>>
>> That was fast. The new test passes.
>
>
> Scott already did the detective work, it was not so difficult. I will have
> to learn git bisect one day.
When you do, remember that 'git bise
Le 23/03/2015 19:45, Kornel Benko a écrit :
That was fast. The new test passes.
Scott already did the detective work, it was not so difficult. I will
have to learn git bisect one day.
JMarc
Lasgouttes
> >> Date: Mon Mar 9 11:14:26 2015 +0100
> >>
> >> Check that DocIterator::sanitize only adds editable insets
> >>
> >> This fixes the crash on ticket #9432, but the bug there has other
> >> causes.
> >
>
Le 21/03/2015 20:42, Scott Kostyshak a écrit :
On Tue, Mar 10, 2015 at 11:17 AM, Jean-Marc Lasgouttes
wrote:
commit 17e435c47e36effd36d25cec900369e04f6acb4e
Author: Jean-Marc Lasgouttes
Date: Mon Mar 9 11:14:26 2015 +0100
Check that DocIterator::sanitize only adds editable insets
> > Check that DocIterator::sanitize only adds editable insets
> >
> > This fixes the crash on ticket #9432, but the bug there has other
> > causes.
>
> This causes a new crash for me:
>
> 1. start a new LyX document
> 2. alt+m f to create a fraction
On Tue, Mar 10, 2015 at 11:17 AM, Jean-Marc Lasgouttes
wrote:
> commit 17e435c47e36effd36d25cec900369e04f6acb4e
> Author: Jean-Marc Lasgouttes
> Date: Mon Mar 9 11:14:26 2015 +0100
>
> Check that DocIterator::sanitize only adds editable insets
>
> This fixes the
Jean-Marc Lasgouttes schreef:
Le 18 avr. 09 à 19:48, Vincent van Ravesteijn a écrit :
Is the attached ok ?
It removes the EDITABLE enum, and makes the editable() function
return a bool.
A lot of editable() functions were not necessary anymore when they
have a hasSettings() functions.
I
Le 18 avr. 09 à 19:48, Vincent van Ravesteijn a écrit :
Is the attached ok ?
It removes the EDITABLE enum, and makes the editable() function
return a bool.
A lot of editable() functions were not necessary anymore when they
have a hasSettings() functions.
I planned to answer at some
ts/InsetIndex.h (working copy)
> @@ -45,7 +45,7 @@
> static void string2params(std::string const &, InsetIndexParams &);
> private:
> ///
> - EDITABLE editable() const { return HIGHLY_EDITABLE; }
> + bool hasSettings() const { return false;
If I add the hasDialog() function, then I should/could remove the
editable() function, right ?
Yes. And you could maybe rename the function to hasSettings()?
Is the attached ok ?
It removes the EDITABLE enum, and makes the editable() function return a
bool.
A lot of editable
Vincent van Ravesteijn writes:
>> So the situation might be bit more complicated than I thought.
> Yes, at least it is very unclear. At first sight I'd have no clue what
> "isActive()" would mean, and wat IS_EDITABLE is and so forth..
If you can think of a good separation of meanings, now would
So what's the difference between isActive() and editable() ==
HIGHLY_EDITABLE ? Might there be a difference for closed
InsetCollapsables ?
Not really. A collapsable changes its editability when collapsed.
Or so I think :) But now that I think of it, I am not really sure.
For examp
Le 16 avr. 09 à 17:07, Vincent van Ravesteijn - TNW a écrit :
Can I just suggest that these be changed e.g. to IN_DIALOG and
ON_SCREEN, if that's more or less what they mean? I've never been
able to remember what EDITABLE vs HIGHLY_EDITABLE means.
That sounds like a good suggestion.
>>> Can I just suggest that these be changed e.g. to IN_DIALOG and
>>> ON_SCREEN, if that's more or less what they mean? I've never been
>>> able to remember what EDITABLE vs HIGHLY_EDITABLE means.
>> That sounds like a good suggestion.
&
;> Inset and it is now checked whether the argument (if one)
>>> corresponds to the current inset.
This is good.
>> Can I just suggest that these be changed e.g. to IN_DIALOG and
>> ON_SCREEN, if that's more or less what they mean? I've never been
>> able to
Vincent van Ravesteijn wrote:
> Ok ?
Could you wait just a bit with this until my indices patch is in?
Jürgen
decide the status we need an updated editable() mechanism in
order to know whether an Inset has inset settings or not. Therefore I
changed the EDITABLE enum into two flags that can be combined. Now
you can also specify InsetCollapsables (HIGHLY_EDITABLE) that do not
have inset settings
an updated editable() mechanism in
order to know whether an Inset has inset settings or not. Therefore I
changed the EDITABLE enum into two flags that can be combined. Now you
can also specify InsetCollapsables (HIGHLY_EDITABLE) that do not have
inset settings (!IS_EDITABLE) (e.g. indices
I propose the following to finish up the recoding of LFUN_INSET_SETTINGS.
- The getStatus() handling of LFUN_INSET_SETTINGS is handled in Inset
and it is now checked whether the argument (if one) corresponds to the
current inset.
- To decide the status we need an updated editable() mechanism
On Wednesday 10 December 2003 06:48 pm, Angus Leeming wrote:
> Kuba Ober wrote:
> > Methinks s/mislead/misled/, but you've had your mandatory punishment
> > anyway and this is just a freebie :)
>
> Well, if you think in American English, then there's nothing I can do
> to help you.
I didn't know i
On Wed, Dec 10, 2003 at 06:45:02PM +, Angus Leeming wrote:
> > Naughty boy, Angus, naughty boy :)
> > s/there/their/
>
> Actually, you're exactly wrong.
Cool stuff. More.
Andre'
Kuba Ober wrote:
> Methinks s/mislead/misled/, but you've had your mandatory punishment
> anyway and this is just a freebie :)
Well, if you think in American English, then there's nothing I can do
to help you.
> Now I'll better shut up lest the gods ban me for being OT and such
My turn to smile
> > Now that the insets are handling [was: there] THEIR own
> > FuncRequests, THERE is no need ...
>
> Ahhh. Context. I was mislead:
Methinks s/mislead/misled/, but you've had your mandatory punishment anyway
and this is just a freebie :)
> > Naughty boy, Angus, naughty boy :)
> > s/there/their/
Kuba Ober wrote:
> Ekhm, this is not an argument. The two sentences you wrote above are
> both correct it seems, yet the one that I pointed to is still wrong
> :)
>
> Now that the insets are handling [was: there] THEIR own
> FuncRequests, THERE is no need ...
Ahhh. Context. I was mislead:
Kuba O
> >> And so, I suspect, is André's assertion that the concept is no
> >> longer needed. Now that insets are handling there
> >
> > Naughty boy, Angus, naughty boy :)
> > s/there/their/
>
> Actually, you're exactly wrong.
I don't think so :)
> 'Where is this concept handled? Over there, in the ins
Kuba Ober wrote:
> On Wednesday 10 December 2003 05:25 am, Angus Leeming wrote:
>> John Levon wrote:
>> > On Wed, Dec 10, 2003 at 09:34:25AM +0100, Andre Poenitz wrote:
>> >> As bold guess: 'noneditable' does not react at all, 'editable'
>&
On Wednesday 10 December 2003 05:25 am, Angus Leeming wrote:
> John Levon wrote:
> > On Wed, Dec 10, 2003 at 09:34:25AM +0100, Andre Poenitz wrote:
> >> As bold guess: 'noneditable' does not react at all, 'editable' has
> >> some dialog atta
On Wed, Dec 10, 2003 at 10:25:41AM +, Angus Leeming wrote:
> John Levon wrote:
>
> > On Wed, Dec 10, 2003 at 09:34:25AM +0100, Andre Poenitz wrote:
> >
> >> As bold guess: 'noneditable' does not react at all, 'editable' has
> >> some di
John Levon wrote:
> On Wed, Dec 10, 2003 at 09:34:25AM +0100, Andre Poenitz wrote:
>
>> As bold guess: 'noneditable' does not react at all, 'editable' has
>> some dialog attached and 'highly editable' is math & inner text.
>
> That&#
On Wed, Dec 10, 2003 at 09:34:25AM +0100, Andre Poenitz wrote:
> As bold guess: 'noneditable' does not react at all, 'editable' has some
> dialog attached and 'highly editable' is math & inner text.
That's exactly correct.
john
--
Khendon'
On Wed, Dec 10, 2003 at 12:28:26AM +0100, Michael Schmitt wrote:
> Just a short question (and hopefully also a short answer):
>
> What is the difference between a noneditable, and editable,
> and a highly editable inset?
If I knew...
As bold guess: 'noneditable'
Just a short question (and hopefully also a short answer):
What is the difference between a noneditable, and editable,
and a highly editable inset?
Please enlighten me,
Michael
47 matches
Mail list logo
