Re: #9708: Cannot step selection back after selecting down out of a multi-line inset

I'll have a look ASAP On Mon, Aug 3, 2015 at 4:51 AM, LyX Ticket Tracker t...@lyx.org wrote: #9708: Cannot step selection back after selecting down out of a multi-line inset ---+- Reporter: skostysh | Owner: lasgouttes Type:

Re: #9708: Cannot step selection back after selecting down out of a multi-line inset

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:

Re: LyX banner has strange bottom line for me

+1 nice! A/ On Wed, May 27, 2015 at 9:55 AM, Enrico Forestieri for...@lyx.org 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

Re: LyX banner has strange bottom line for me

+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

Re: cursor movement / usability annoyances

On Fri, Feb 27, 2015 at 6:17 PM, Scott Kostyshak skost...@lyx.org 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/

Re: cursor movement / usability annoyances

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/

Re: cursor movement / usability annoyances

On Thu, Feb 26, 2015 at 1:02 AM, mark.braving...@csiro.au wrote: Tue, Feb 24, 2015 at 11:33 PM, mark.braving...@csiro.au 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

Re: cursor movement / usability annoyances

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

Re: cursor movement / usability annoyances

On Tue, Feb 24, 2015 at 11:33 PM, mark.braving...@csiro.au 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

Re: cursor movement / usability annoyances

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

Re: Test

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 rgh...@lyx.org wrote: This is a test.

Re: Test

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. >

Re: Lyx.org seems to be down

It's not for me, or at least not anymore. A/ On Mon, Dec 29, 2014 at 12:54 PM, Kornel Benko kor...@lyx.org wrote: Kornel

Re: Lyx.org seems to be down

It's not for me, or at least not anymore. A/ On Mon, Dec 29, 2014 at 12:54 PM, Kornel Benko wrote: > > Kornel

Re: Flex prefix strip-off bug (?)

(-1)*(-1) A/ On Mon, Dec 8, 2014 at 9:24 AM, Jean-Marc Lasgouttes lasgout...@lyx.org 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.

Re: Flex prefix strip-off bug (?)

(-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

Re: Flex prefix strip-off bug (?)

On Sun, Dec 7, 2014 at 8:09 PM, Jean-Marc Lasgouttes lasgout...@lyx.org 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

Re: Flex prefix strip-off bug (?)

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,

Re: Help with patch for word selection mode on double click

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,

Re: Help with patch for "word selection mode" on double click

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,

Re: [PATCH] Do not enable switching notes to same type

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 kor...@lyx.org wrote: Am Mittwoch, 12. November 2014 um 10:30:53,

Re: [PATCH] Do not enable switching notes to same type

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

Re: Problem with copy

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

Re: Problem with copy

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

Re: Problem with copy

On Wed, Oct 22, 2014 at 5:47 AM, Cyrille Artho c.ar...@aist.go.jp 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

Re: Problem with copy

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

Re: Problem with copy

, Oct 20, 2014 at 9:08 PM, Richard Heck rgh...@lyx.org 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 consistently. A second copy doesn't

Re: Problem with copy

, Oct 20, 2014 at 9:08 PM, Richard Heck <rgh...@lyx.org> 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 >&

Problem with copy

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

Problem with copy

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

Re: [PATCH] Add LFUN_SERVER_GET_STATISTICS command

On Sun, Oct 19, 2014 at 4:16 PM, Jean-Marc Lasgouttes lasgout...@lyx.org 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 constraints (e.g. # words

Re: [PATCH] Add LFUN_SERVER_GET_STATISTICS command

On Sun, Oct 19, 2014 at 4:16 PM, Jean-Marc Lasgouttes <lasgout...@lyx.org> 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

Re: [PATCH] Add LFUN_SERVER_GET_STATISTICS command

and equations, that are counted separately with their own measure... On Sat, Oct 18, 2014 at 3:03 PM, Jürgen Spitzmüller sp...@lyx.org 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 writing a document with length

Re: [PATCH] Add LFUN_SERVER_GET_STATISTICS command

and equations, that are counted separately with their own measure... On Sat, Oct 18, 2014 at 3:03 PM, Jürgen Spitzmüller <sp...@lyx.org> wrote: > Alfredo Braunstein wrote: >> I see. IMO the LFUN way is preferable. I'll give one use case where I >> would find this useful: wh

Re: [PATCH] Add LFUN_SERVER_GET_STATISTICS command

On Fri, Oct 17, 2014 at 9:57 AM, Jean-Marc Lasgouttes lasgout...@lyx.org 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

Re: [PATCH] Add LFUN_SERVER_GET_STATISTICS command

). A/ On Fri, Oct 17, 2014 at 6:14 PM, Pavel Sanda sa...@lyx.org 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's part of the document

Re: [PATCH] Add LFUN_SERVER_GET_STATISTICS command

On Fri, Oct 17, 2014 at 6:56 PM, Alfredo Braunstein abrau...@lyx.org 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 accessible

Re: [PATCH] Add LFUN_SERVER_GET_STATISTICS command

Just tested and you're right. A/ On Fri, Oct 17, 2014 at 9:23 PM, Pavel Sanda sa...@lyx.org 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 part). IIRC statistics

Re: [PATCH] Add LFUN_SERVER_GET_STATISTICS command

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

Re: [PATCH] Add LFUN_SERVER_GET_STATISTICS command

). A/ On Fri, Oct 17, 2014 at 6:14 PM, Pavel Sanda <sa...@lyx.org> 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? &g

Re: [PATCH] Add LFUN_SERVER_GET_STATISTICS command

On Fri, Oct 17, 2014 at 6:56 PM, Alfredo Braunstein <abrau...@lyx.org> 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 th

Re: [PATCH] Add LFUN_SERVER_GET_STATISTICS command

Just tested and you're right. A/ On Fri, Oct 17, 2014 at 9:23 PM, Pavel Sanda <sa...@lyx.org> 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

Re: Fix #9201 (advanced find matches note in front of search term, dataloss)

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 sp...@lyx.org wrote: 2014-10-14 22:25 GMT+02:00 Alfredo Braunstein: Btw, are there other insets besides InsetNote that could produce no output

Re: Fix #9201 (advanced find matches note in front of search term, dataloss)

On Wed, Oct 15, 2014 at 10:31 AM, Jean-Marc Lasgouttes lasgout...@lyx.org 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 sr (although some of these maybe

Re: Fix #9201 (advanced find matches note in front of search term, dataloss)

On Wed, Oct 15, 2014 at 11:37 AM, Jean-Marc Lasgouttes lasgout...@lyx.org 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 Search replace all [math:x]-[math:y] in a document

Re: Fix #9201 (advanced find matches note in front of search term, dataloss)

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 in

Re: Fix #9201 (advanced find matches note in front of search term, dataloss)

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 <sp...@lyx.org> wrote: > 2014-10-14 22:25 GMT+02:00 Alfredo Braunstein: >> >> Btw, are there other insets besides InsetNo

Re: Fix #9201 (advanced find matches note in front of search term, dataloss)

On Wed, Oct 15, 2014 at 10:31 AM, Jean-Marc Lasgouttes <lasgout...@lyx.org> 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 a

Re: Fix #9201 (advanced find matches note in front of search term, dataloss)

On Wed, Oct 15, 2014 at 11:37 AM, Jean-Marc Lasgouttes <lasgout...@lyx.org> 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. >> &

Re: Fix #9201 (advanced find matches note in front of search term, dataloss)

> 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

Re: #9145: LyX crash while accepting a change (reopened)

On Mon, Oct 13, 2014 at 6:27 PM, Jean-Marc Lasgouttes lasgout...@lyx.org wrote: Le 13/10/2014 18:15, Alfredo Braunstein a écrit : The fix however seems bogus to me: -cur.forwardPos(); +cur.top().forwardPos(); Why bogus? Why do you want to revert

Re: Fix #9291

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.dispatched() statements

Re: #9145: LyX crash while accepting a change (reopened)

On Tue, Oct 14, 2014 at 8:51 AM, Alfredo Braunstein abrau...@lyx.org wrote: On Mon, Oct 13, 2014 at 6:27 PM, Jean-Marc Lasgouttes lasgout...@lyx.org wrote: Le 13/10/2014 18:15, Alfredo Braunstein a écrit : The fix however seems bogus to me: -cur.forwardPos

Re: #9145: LyX crash while accepting a change (reopened)

ok, done. A/ On Tue, Oct 14, 2014 at 5:33 PM, Richard Heck rgh...@lyx.org wrote: On 10/14/2014 11:17 AM, Alfredo Braunstein wrote: On Tue, Oct 14, 2014 at 8:51 AM, Alfredo Braunstein abrau...@lyx.org wrote: On Mon, Oct 13, 2014 at 6:27 PM, Jean-Marc Lasgouttes lasgout...@lyx.org wrote

Fix #9201 (advanced find matches note in front of search term, dataloss)

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 sr. I set it to true also for the stringification of the search buffer, so now

Re: Policy on non-translated examples

On Tue, Oct 14, 2014 at 8:04 PM, Scott Kostyshak skost...@lyx.org wrote: On Thu, Oct 9, 2014 at 8:35 AM, Scott Kostyshak skost...@lyx.org 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

Re: Fix #9201 (advanced find matches note in front of search term, dataloss)

On Tue, Oct 14, 2014 at 7:47 PM, Alfredo Braunstein abrau...@lyx.org 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 advanced

Re: #9145: LyX crash while accepting a change (reopened)

On Mon, Oct 13, 2014 at 6:27 PM, Jean-Marc Lasgouttes <lasgout...@lyx.org> wrote: > Le 13/10/2014 18:15, Alfredo Braunstein a écrit : >>>> >>>> The fix however seems bogus to me: >>> >>> >>> >>>> -cur.forward

Re: Fix #9291

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

Re: #9145: LyX crash while accepting a change (reopened)

On Tue, Oct 14, 2014 at 8:51 AM, Alfredo Braunstein <abrau...@lyx.org> wrote: > On Mon, Oct 13, 2014 at 6:27 PM, Jean-Marc Lasgouttes > <lasgout...@lyx.org> wrote: >> Le 13/10/2014 18:15, Alfredo Braunstein a écrit : >>>>>

Re: #9145: LyX crash while accepting a change (reopened)

ok, done. A/ On Tue, Oct 14, 2014 at 5:33 PM, Richard Heck <rgh...@lyx.org> wrote: > On 10/14/2014 11:17 AM, Alfredo Braunstein wrote: >> >> On Tue, Oct 14, 2014 at 8:51 AM, Alfredo Braunstein <abrau...@lyx.org> >> wrote: >>> >>> On Mon, Oct 13,

Fix #9201 (advanced find matches note in front of search term, dataloss)

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 I set it to true also for the stringification of the search buffer, so now

Re: Policy on non-translated examples

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 >>

Re: Fix #9201 (advanced find matches note in front of search term, dataloss)

On Tue, Oct 14, 2014 at 7:47 PM, Alfredo Braunstein <abrau...@lyx.org> 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 &g

#9145: LyX crash while accepting a change (reopened)

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

Re: Insert Float Figure Wrap Float does not float by default

On Mon, Oct 13, 2014 at 12:00 AM, Scott Kostyshak skost...@lyx.org 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

Re: #9145: LyX crash while accepting a change (reopened)

On Mon, Oct 13, 2014 at 5:39 PM, Jean-Marc Lasgouttes lasgout...@lyx.org wrote: Le 13/10/2014 14:29, Alfredo Braunstein a écrit : The fix however seems bogus to me: -cur.forwardPos(); +cur.top().forwardPos(); Why bogus? Why do you want to revert it? To me

Re: Insert Float Figure Wrap Float does not float by default

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 feedback!

#9145: LyX crash while accepting a change (reopened)

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

Re: "Insert > Float > Figure Wrap Float" does not float by default

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

Re: #9145: LyX crash while accepting a change (reopened)

On Mon, Oct 13, 2014 at 5:39 PM, Jean-Marc Lasgouttes <lasgout...@lyx.org> wrote: > Le 13/10/2014 14:29, Alfredo Braunstein a écrit : >> >> The fix however seems bogus to me: > > >> -cur.forwardPos(); >> +cur.top().forward

Re: "Insert > Float > Figure Wrap Float" does not float by default

> 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

Re: [ticket #9290] Selection in nested insets is sometimes irreversible

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).

Re: line-end in math

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/

Fix #9291

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

Re: Insert Float Figure Wrap Float does not float by default

On Sun, Oct 12, 2014 at 9:58 PM, Scott Kostyshak skost...@lyx.org 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

Re: [ticket #9290] Selection in nested insets is sometimes irreversible

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).

Re: line-end in math

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/

Fix #9291

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

Re: "Insert > Float > Figure Wrap Float" does not float by default

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 >

[ticket #9290] Selection in nested insets is sometimes irreversible

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

Re: [ticket #9290] Selection in nested insets is sometimes irreversible

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 an

Re: [ticket #9290] Selection in nested insets is sometimes irreversible

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.

[ticket #9290] Selection in nested insets is sometimes irreversible

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

Re: [ticket #9290] Selection in nested insets is sometimes irreversible

> 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

Re: [ticket #9290] Selection in nested insets is sometimes irreversible

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.

Re: line-end in math

Alfredo Braunstein wrote: Scott Kostyshak wrote: On Tue, Oct 7, 2014 at 10:18 AM, Alfredo Braunstein abrau...@lyx.org wrote: 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

Re: line-end in math

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

Re: line-end in math

Alfredo Braunstein wrote: > Scott Kostyshak wrote: > >> On Tue, Oct 7, 2014 at 10:18 AM, Alfredo Braunstein <abrau...@lyx.org> >> wrote: >>> Alfredo Braunstein wrote: >>> >>>> Now if the situation is >>>> >>>

Re: line-end in math

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

Re: line-end in math

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 is also a way of triggering http://www.lyx.org/trac/ticket/3900 (Mathed corners

Re: line-end in math

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

Re: line-end in math

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 by the inner insets?) and what

Re: line-end in math

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 displayed without mouse hover, now closed/fixed

Re: line-end in math

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 cursor escapes wrongly the math inset, purple

Re: line-end in math

Scott Kostyshak wrote: On Tue, Oct 7, 2014 at 10:18 AM, Alfredo Braunstein abrau...@lyx.org wrote: 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

Re: line-end in math

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.org/trac/ticket/3900 (Mathed corners displayed without mouse

Re: line-end in math

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 by the

Re: line-end in math

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 displayed

Re: line-end in math

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

  1   2   3   4   5   6   7   8   9   10   >