Re: #9434: In version 2.1.3, paste pastes into multiple random places
On Thu, Feb 26, 2015 at 1:58 PM, Justin Smith wrote: > On 02/26/2015 01:50 PM, LyX Ticket Tracker wrote: >> >> #9434: In version 2.1.3, paste pastes into multiple random places >> -+- >> Reporter: jsmith | Owner: lasgouttes >> Type: defect | Status: new >> Priority: normal | Milestone: 2.1.4 >> Component: general | Version: 2.1.3 >> Severity: blocker | Resolution: >> Keywords: | >> -+- >> >> Comment (by skostysh): >> >> What is your operating system? For some reason, we've seen similar >> behavior to what you report but from what I know it's only from users on >> Windows. >> >> Also, do you suspend/resume? >> > The problem is resolved --- I was using Linux and the mouse wheel was > pasting text into various places. I disabled it and the problem has not > occurred again. Sorry to bother you! Glad you got it figured out, Justin. You might be interested in knowing that starting in LyX 2.2.0 there will be an option for disabling the middle button paste in LyX. For more information, see: http://www.lyx.org/trac/ticket/9399 Best, Scott
Re: [patches] Improve error reporting and log parsing
On Thu, Feb 26, 2015 at 4:24 PM, Enrico Forestieri wrote: > On Thu, Feb 26, 2015 at 12:57:24PM -0500, Scott Kostyshak wrote: >> On Wed, Feb 25, 2015 at 4:33 PM, Scott Kostyshak wrote: >> > On Wed, Feb 25, 2015 at 4:07 PM, Georg Baum >> >> >> IMHO it can be made an error right away. >> > >> > I would be OK with making it an error right away. The argument for >> > first making it a warning is that from the user perspective, the >> > documents stop compiling. We had a similar discussion with BibTeX. We >> > currently do not report BibTeX errors. Jurgen implemented support for >> > reporting errors (7e188c51) but had to revert (148317b6) because of >> > user complaints. >> >> Does anyone else have an opinion on this? I am fine either way. At >> first I assumed that because of the BibTeX issue we should be >> consistent with our decision on that. But perhaps this is different in >> some way? > > My vote is for a warning and an output produced in any case. > If latex produces an output, that output has to be shown, IMO. > Having the possibility of looking at the output may be of great > help to pinpoint problems. Interesting idea. If we do this, we should do it for all errors. With this commit I'm just proposing to (either directly or in a future version) add NONZERO_ERROR to be treated as other errors (by adding NONZERO_ERROR to ERRORS = TEX_ERROR + LATEX_ERROR in LaTeX.h). As for how we handle ERRORS, we could do what you suggest and check whether a PDF was created. Scott
Re: lyx crashes when applying long table settings
On 02/26/2015 05:40 PM, Stephanie Andrews wrote: Dear developers, I'm using lyx version 2.1.1 and found possibly a bug which seems similar to the problem reported here: http:/www.lyx.org/trac/ticket/8721 Inserting a table, setting it to long format, marking the whole table, changing text style - customize - size smaller results in lyx crashing. Hi, Stephanie, Thanks for the report, and sorry you are having this problem. I tried exactly what you describe with LyX 2.1.3, and did not get a crash. Can you try updating to this version? If you do still get the crash, please provide us with as exact a recipe as possible to reproduce it reliably, if you are able to do that. We take crashes very seriously and do our best to fix them ASAP. Richard
lyx crashes when applying long table settings
Dear developers, I'm using lyx version 2.1.1 and found possibly a bug which seems similar to the problem reported here: http:/www.lyx.org/trac/ticket/8721 Inserting a table, setting it to long format, marking the whole table, changing text style - customize - size smaller results in lyx crashing. Thanks!
Re: [patches] Improve error reporting and log parsing
On Thu, Feb 26, 2015 at 12:57:24PM -0500, Scott Kostyshak wrote: > On Wed, Feb 25, 2015 at 4:33 PM, Scott Kostyshak wrote: > > On Wed, Feb 25, 2015 at 4:07 PM, Georg Baum > > >> IMHO it can be made an error right away. > > > > I would be OK with making it an error right away. The argument for > > first making it a warning is that from the user perspective, the > > documents stop compiling. We had a similar discussion with BibTeX. We > > currently do not report BibTeX errors. Jurgen implemented support for > > reporting errors (7e188c51) but had to revert (148317b6) because of > > user complaints. > > Does anyone else have an opinion on this? I am fine either way. At > first I assumed that because of the BibTeX issue we should be > consistent with our decision on that. But perhaps this is different in > some way? My vote is for a warning and an output produced in any case. If latex produces an output, that output has to be shown, IMO. Having the possibility of looking at the output may be of great help to pinpoint problems. -- Enrico
Re: #9434: In version 2.1.3, paste pastes into multiple random places
On 02/26/2015 01:50 PM, LyX Ticket Tracker wrote: #9434: In version 2.1.3, paste pastes into multiple random places -+- Reporter: jsmith | Owner: lasgouttes Type: defect | Status: new Priority: normal | Milestone: 2.1.4 Component: general | Version: 2.1.3 Severity: blocker | Resolution: Keywords: | -+- Comment (by skostysh): What is your operating system? For some reason, we've seen similar behavior to what you report but from what I know it's only from users on Windows. Also, do you suspend/resume? The problem is resolved --- I was using Linux and the mouse wheel was pasting text into various places. I disabled it and the problem has not occurred again. Sorry to bother you!
Re: [patches] Improve error reporting and log parsing
On Wed, Feb 25, 2015 at 4:33 PM, Scott Kostyshak wrote: > On Wed, Feb 25, 2015 at 4:07 PM, Georg Baum >> IMHO it can be made an error right away. > > I would be OK with making it an error right away. The argument for > first making it a warning is that from the user perspective, the > documents stop compiling. We had a similar discussion with BibTeX. We > currently do not report BibTeX errors. Jurgen implemented support for > reporting errors (7e188c51) but had to revert (148317b6) because of > user complaints. Does anyone else have an opinion on this? I am fine either way. At first I assumed that because of the BibTeX issue we should be consistent with our decision on that. But perhaps this is different in some way? Scott
Re: [LyX/master] Some performance stuff reported by cppcheck
Le 25/02/2015 02:06, Richard Heck a écrit : Some performance stuff reported by cppcheck I cannot use left and right cursor movements after this commit. Am I the only one? Note that I'm using Qt 5. I see it, too, and have fixed it. Thanks for that, but why is this needed? JMarc
Re: cursor movement / usability annoyances
On 02/25/2015 07:02 PM, mark.braving...@csiro.au 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 cursor-movement keys as more predictable and requiring less conscious control. But the key-based motion actually feels quite unpredictable and--- crucially--- it's non- reversible. Am I the only one? You are not ;-) - When selecting/highlighting text within an equation/cell/table, with SHIFT pressed: go one character outside the cell, and the whole cell is instantly selected (thus suddenly moving the _starting_ point of the selection _backwards_), and there is no way to reverse the step. Since "characters" aren't all the same size and it's sometimes hard to locate the invisible boundary of an equation/cell/table, this is a pretty easy mistake to make. This is one case where I do sometimes do use the mouse (with SHIFT pressed), and then it's even worse because the mouse sensitivity is so high. Try selecting the rest of a long piece of text from the current cursor position to the end of the cell _without_ selecting the entire cell. I bet it'll take you 2 or 3 attempts. I fixed some of these issues about selection somewhat recently and the fixes are in the devel version; I don't know if they are in a stable version yet. The release notes for new version 2.1.3 mention "inset-select-all", which may be related (but isn't the whole story). I think we did not put this into stable, as it touched a lot of code. But if someone would like to prepare a patch, I'd be happy to have a look at it. Richard
Re: [patch idea] TeX code inset for math
On 2015-02-25, Georg Baum wrote: > Guenter Milde wrote: > The only question is: Is it guaranteed that a macro name can never contain > an underscore in LaTeX or TeX? If yes, then this would be quite easy to > implement at file format level. a) a macro name may contain any ACII character, if it is specified via \csname any ASCII ^_ string\endcsname b) following a \, the TeX parser will treat either all following letters (no underscore, no hyphen, nott even numbers) or the following non-letter character (as in the accten macros \', \~, ...) as macro name. While it is possible to change the set treated as letters (cf. \makeatletter), IMO we can be sure that the underscore will not be made a letter in math. OTOH, beware that e.g. $\sum_i$ is valid math inptu for a sum over index i! Günter
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 cursor-movement keys as more >> predictable and requiring less conscious control. But the key-based motion >> actually feels quite unpredictable and--- crucially--- it's non- >> reversible. Am I the only one? >> >> You are not ;-) >> >> > - When selecting/highlighting text within an equation/cell/table, with >> SHIFT pressed: go one character outside the cell, and the whole cell is >> instantly selected (thus suddenly moving the _starting_ point of the >> selection _backwards_), and there is no way to reverse the step. Since >> "characters" aren't all the same size and it's sometimes hard to locate >> the invisible boundary of an equation/cell/table, this is a pretty easy >> mistake to make. This is one case where I do sometimes do use the mouse >> (with SHIFT pressed), and then it's even worse because the mouse >> sensitivity is so high. Try selecting the rest of a long piece of text >> from the current cursor position to the end of the cell _without_ >> selecting the entire cell. I bet it'll take you 2 or 3 attempts. >> >> I fixed some of these issues about selection somewhat recently and the >> fixes are in the devel version; I don't know if they are in a stable >> version yet. > > The release notes for new version 2.1.3 mention "inset-select-all", which may > be related (but isn't the whole story). > >> >> > Reversibility aside, I'm not sure whether there's a "solution" to the >> > seeming unpredictability of movement--- though it would be great if >> > there was. However, I would certainly find it useful to have an option >> > *not* to move outside the equation (table, box,...) unless Lyx is >> > specifically told to. (That specific idea may not make any sense; I'm >> > just trying to start a discussion.) >> >> I completely understand your point. One possibility to have reversibility >> could be to implement "logical" movement (i.e. move to the next/previous >> valid cursor position in the document without attempting to use visual >> information). Then you could bind it to the left and right keys, so that >> right -> left will be guaranteed to be an identity. This seems super easy >> to do. > > That sounds great! Note that such approach would have drawbacks: - cursor movement could be counter-intuitive: e.g. cursor right on the last cell of a line other than the last in a multi-line equation would go to the first cell of the next line instead of exiting the inset - there is no reasonable way of implementing "logical" cursor up / down that I can think of > No rush, but if you can let me know when there is a trial patch, I'll see if > I can persuade a Linux > colleague to download & install a development version for testing. (I'm stuck > with Windows and > don't know my way round the installation intricacies.) can you persuade your linux colleague to implement it? If he installs the devel version he would be half-way! ;-) A/
