Re: [patch] RFC: better submenu for tables

Le 12/11/2015 00:39, Uwe Stöhr a écrit : Am 11.11.2015 um 13:52 schrieb Guillaume Munch: Yes, I committed now a version which includes your and also JMarc's changes. Thanks again P.S.: it might be good to disable "inset-modify tabular multi(column|row)" when a single cell

Re: [patch] RFC: better submenu for tables

Le 12/11/2015 00:34, Uwe Stöhr a écrit : Am 11.11.2015 um 13:57 schrieb Guillaume Munch: Well multirow and multicolumn is about cells, so I moved it with cells. multirow can be for several cells but also for complete rows. Therefore I don't think it is sensible to have a special cell

Re: [patch] RFC: better submenu for tables

Le 12/11/2015 00:30, Uwe Stöhr a écrit : Am 11.11.2015 um 13:13 schrieb Jean-Marc Lasgouttes: Many Thanks for reviewing. Since the menu name is about lines, should we just have entry Top/Bottom... Done. What about putting multirow with rows and multicolumns with columns? That#s a matter

Re: beamer workflow

Le 12/11/2015 09:19, Edwin Leuven a écrit : On 11 Nov 2015, at 19:07, Jürgen Spitzmüller wrote: Am Dienstag 10 November 2015, 10:21:02 schrieb Edwin Leuven: dear all, when i insert a new frame, add the title and hit enter the new line is set to “Frame” similarly if i am editing the content

[PATCH] Bug #9854 "Dataloss after git merge with change tracking"

27;s the problem typically. Here have a look at operator>> in Author.cpp below. What's the problem and what should typically be done there? Scott, this can wait until after alpha, as you want. Sincerely, Guillaume >From d6a7ae1ab965f9cde4b0dd5df1716f50aafbe010 Mon Sep 17 00:00:00 2001

Re: [patch] RFC: better submenu for tables

Le 11/11/2015 12:57, Guillaume Munch a écrit : Le 11/11/2015 12:13, Jean-Marc Lasgouttes a écrit : Le 11/11/2015 01:53, Uwe Stöhr a écrit : I agree that submenus are better than to remove things. Attached is a patch. OK to go in? Thanks, we need something like that. A few comments

Re: [patch] RFC: better submenu for tables

Le 11/11/2015 12:13, Jean-Marc Lasgouttes a écrit : Le 11/11/2015 01:53, Uwe Stöhr a écrit : I agree that submenus are better than to remove things. Attached is a patch. OK to go in? Thanks, we need something like that. A few comments: Sorry, our messages crossed each-other. I could not con

Re: [patch] RFC: better submenu for tables

Le 11/11/2015 00:53, Uwe Stöhr a écrit : Am 04.11.2015 um 10:42 schrieb Jean-Marc Lasgouttes: This is not how contextual menus are supposed to work IMO. I would propose instead to use submenus and to micmick what libreoffice (for ex.) does. I agree that submenus are better than to remove thin

Re: Tentative schedule for 2.2.0 release

Le 11/11/2015 08:02, Scott Kostyshak a écrit : Below is a tentative schedule for releasing 2.2.0. I think the schedule is slightly on the aggressive side, and that is because I think the state of our master branch is already relatively stable. alpha: tag and tar this week and announce this weeke

Re: [patch] Finding the generated latex file

Le 10/11/2015 01:08, Scott Kostyshak a écrit : On Mon, Nov 09, 2015 at 08:04:29AM +, Guillaume Munch wrote: Le 06/11/2015 10:35, Jean-Marc Lasgouttes a écrit : Le 06/11/2015 04:16, Scott Kostyshak a écrit : I also agree that it's better to replace the alert with a message on stde

Re: Plan for the current testing situation

Le 02/11/2015 03:41, Scott Kostyshak a écrit : Thanks to all of those participating in the discussions about tests. I have learned a lot the last couple of weeks. Thank you also to those who have tried to run the tests. This to me is a great step forward. I know that the export tests are sloppy c

Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

Le 08/11/2015 16:16, Georg Baum a écrit : Richard Heck wrote: On 11/07/2015 12:36 AM, Vincent van Ravesteijn wrote: Is it really a file format change? If we do not change the physical appearance of the file format, and if we do not change the document output of a certain file, is it then stil

Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

Le 07/11/2015 21:18, Pavel Sanda a écrit : Guillaume Munch wrote: Have a new checkbox in document settings labelled "Open with change tracking enabled". Then the current state of change tracking is made independent from this checkbox; only, if the box is checked then it will do as adv

Re: [patch] Finding the generated latex file

Le 06/11/2015 10:35, Jean-Marc Lasgouttes a écrit : Le 06/11/2015 04:16, Scott Kostyshak a écrit : I also agree that it's better to replace the alert with a message on stderr. I noticed that there are already similar messages on the terminal when files cannot be removed. Attached is a patch. Sh

Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

Le 07/11/2015 22:17, Richard Heck a écrit : On 11/07/2015 04:46 PM, Jean-Marc Lasgouttes wrote: Le 7 novembre 2015 02:02:27 GMT+01:00, Guillaume Munch a écrit : Yes, I fully understand this point and I agree that a decision has to be taken somehow quickly, this is why I brought the subject

Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

Le 06/11/2015 21:42, Georg Baum a écrit : I think there is general consensus about \justification and \output_changes, so if this is OK with Scott you could move these to preferences, but for \track_changes I do not see a consensus, so this setting should not be changed so short before a releas

Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

Le 06/11/2015 21:46, Guillaume Munch a écrit : Le 06/11/2015 21:28, Georg Baum a écrit : Guillaume Munch wrote: Le 06/11/2015 09:06, Jean-Marc Lasgouttes a écrit : Le 06/11/2015 02:31, Guillaume Munch a écrit : In terms of least surprise, I would add that both msword 2007 and libreoffice 5

Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

Le 06/11/2015 21:28, Georg Baum a écrit : Guillaume Munch wrote: Le 06/11/2015 09:06, Jean-Marc Lasgouttes a écrit : Le 06/11/2015 02:31, Guillaume Munch a écrit : In terms of least surprise, I would add that both msword 2007 and libreoffice 5 store the setting in the document and consider

Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

Le 06/11/2015 04:37, Pavel Sanda a écrit : Guillaume Munch wrote: express any intention. Your description gives the impression that if your collaborator starts writing and they do not see that the changes are not being tracked, then they will not know or care about enabling change tracking, as

Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

Le 06/11/2015 09:06, Jean-Marc Lasgouttes a écrit : Le 06/11/2015 02:31, Guillaume Munch a écrit : Besides the lack of intention conveyed, I already mentioned the principle of least surprise: it is not clear for a new user that this is a purpose of the button. So if what is currently

Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

Le 06/11/2015 07:01, Vincent van Ravesteijn a écrit : Op 6 nov. 2015 05:44 schreef "Pavel Sanda" mailto:sa...@lyx.org>>: > > Guillaume Munch wrote: > > That "CT lock" feature, instead of imposing such a strict constraint > > (that could always be

Re: screen indenting after frames

Le 06/11/2015 07:34, Jürgen Spitzmüller a écrit : Am Donnerstag 05 November 2015, 18:57:52 schrieb Edwin Leuven: i agree may i suggest that you push this change to master? I've pushed something similar. Might be something to consider for branch. Jürgen Thank you!

Re: [patch] Finding the generated latex file

Le 06/11/2015 03:16, Scott Kostyshak a écrit : On Fri, Nov 06, 2015 at 02:32:13AM +, Guillaume Munch wrote: Le 04/11/2015 17:16, PhilipPirrip a écrit : I personally find this very annoying. As a user. It doesn't happen on Linux, so I'm still good, but on Windows: I tested th

Re: [patch] Finding the generated latex file

Le 04/11/2015 17:16, PhilipPirrip a écrit : I personally find this very annoying. As a user. It doesn't happen on Linux, so I'm still good, but on Windows: I tested the patch on Windows, no messages were shown if LyX was closed, Windows Explorer window would just close upon the deletion of the t

Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

Le 05/11/2015 20:25, Georg Baum a écrit : Guillaume Munch wrote: Le 04/11/2015 20:06, Georg Baum a écrit : My experience with multi-author collaboration and change tracking differs. The various portions of the document tend to "belong" to one author and an author uses chang

Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

Le 05/11/2015 07:31, Vincent van Ravesteijn a écrit : On Thu, Nov 5, 2015 at 7:12 AM, Pavel Sanda wrote: Vincent van Ravesteijn wrote: I consider it also document, not user, setting. It would cause confusions if this setting is not transfered to my collaborators within the document. I disagr

Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

Le 04/11/2015 20:06, Georg Baum a écrit : Guillaume Munch wrote: Le 03/11/2015 21:16, Georg Baum a écrit : I don't think there is an easy solution, because it depends on the use case. For example, in our documentation workflows \tracking_changes needs to be the same for all users, so

Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

Le 03/11/2015 21:16, Georg Baum a écrit : Guillaume Munch wrote: <http://www.lyx.org/trac/ticket/9841> I am bringing this to the list due to the timing, due to the fact that it is a file format change, and due to the fact that it looks severe in the above context. I suggest moving

Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

Le 03/11/2015 19:49, LyX Ticket Tracker a écrit : #9841: Preferences specific to the user and not to the file should not be recorded in the file -+ Reporter: gadmm| Owner: lasgouttes Type: defect | Status: new Priority: no

Re: [patch] Finding the generated latex file

Le 03/11/2015 16:39, Guillaume Munch a écrit : Le 03/11/2015 16:16, Stephan Witt a écrit : Am 03.11.2015 um 16:36 schrieb Guillaume Munch : Do you mean that the patch now causes this error message? Under which circumstances precisely? Is it that if the directory is open in the finder, then

Re: [patch] Finding the generated latex file

Le 03/11/2015 16:16, Stephan Witt a écrit : Am 03.11.2015 um 16:36 schrieb Guillaume Munch : Do you mean that the patch now causes this error message? Under which circumstances precisely? Is it that if the directory is open in the finder, then LyX cannot remove the directory? (Under Linux

Re: [LyX/master] Add "Open Containing Directory" button to the log dialog (#9211, #9834)

Le 03/11/2015 16:10, Kornel Benko a écrit : It is the same, opens with gvim. But in the mean time I learned a new gvim command ':Ex[plore]', which shows the content of this directory. And one can select files (e.g. click on filenames) and open them. For me it is OK ... OK. Only thing is th

Re: [patch] Finding the generated latex file

Le 03/11/2015 08:59, Stephan Witt a écrit : Am 03.11.2015 um 04:58 schrieb Guillaume Munch mailto:g...@lyx.org>>: Le 02/11/2015 18:38, Guillaume Munch a écrit : Le 28/10/2015 16:39, Ilan a écrit : Thanks David and Stephan. My problem is that I'm working on a multi-file project s

Re: [patch] Finding the generated latex file

Le 03/11/2015 08:27, PhilipPirrip a écrit : On 11/02/2015 10:58 PM, Guillaume Munch wrote: Pushed at f441590c. Windows/OSX users, please report if it does not work. Hey Guillaume, Bad news, it didn't work on Windows. Qt 4.8, VS2010, WinXP/VirtualBox This was the error message: ly

Re: [LyX/master] Add "Open Containing Directory" button to the log dialog (#9211, #9834)

Le 03/11/2015 08:32, Jean-Marc Lasgouttes a écrit : Le 03/11/2015 04:57, Guillaume Munch a écrit : commit f441590c8e0b5e970fbdd656198ec4993dfecb43 Author: Guillaume Munch Date: Mon Nov 2 18:19:40 2015 + Add "Open Containing Directory" button to the log dialog (#9

Re: [LyX/master] Add "Open Containing Directory" button to the log dialog (#9211, #9834)

Le 03/11/2015 07:35, Kornel Benko a écrit : Am Dienstag, 3. November 2015 um 04:57:45, schrieb Guillaume Munch commit f441590c8e0b5e970fbdd656198ec4993dfecb43 Author: Guillaume Munch Date: Mon Nov 2 18:19:40 2015 + Add "Open Containing Directory" button to the log dia

Re: [patch] Finding the generated latex file

Le 02/11/2015 18:38, Guillaume Munch a écrit : Le 28/10/2015 16:39, Ilan a écrit : Thanks David and Stephan. My problem is that I'm working on a multi-file project so under the tmp directory there are several directories and the location of the Latex file depends on the file I compiled (a

Re: [patch] Finding the generated latex file

Le 03/11/2015 00:41, Scott Kostyshak a écrit : On Tue, Nov 03, 2015 at 12:11:08AM +, Guillaume Munch wrote: The "Open directory..." could also get rid of the "Show Output Anyway" button for the same reasoning as (1) above. I like the "Show Output Anyway" butt

Re: [patch] Finding the generated latex file

Le 02/11/2015 23:50, Scott Kostyshak a écrit : On Mon, Nov 02, 2015 at 09:49:24PM +, Guillaume Munch wrote: Le 02/11/2015 21:10, Andrew Parsloe a écrit : Your proposed button would also solve #9211 "Make the lyxpreview.log files accessible within LyX". I agree, part of this

Re: [patch] Finding the generated latex file

use button ▷ Select all, then copy. Any user of the "Copy to clipboard" button would object? I propose to commit the attached which solves the UI issues of the previous patch. Guillaume >From ea6b85adc95be9625a203f35009edfe5ee0deee5 Mon Sep 17 00:00:00 2001 From: Guillaume Munch

[patch] Finding the generated latex file

not too bad to expose the LyX internals in this way. What do you think? Guillaume >From 7f97044ddbe67ccd83c6460878045aabf134c443 Mon Sep 17 00:00:00 2001 From: Guillaume Munch Date: Mon, 2 Nov 2015 18:19:40 + Subject: [PATCH] Add "Open directory..." button to the log dialog. Proof of

Re: #9785: lstinline in footnotes

Dear Uwe, Le 27/10/2015 00:40, Uwe Stöhr a écrit : Am 26.10.2015 um 17:21 schrieb Guillaume Munch: The user reported two valid use cases that are exceptions to this behaviour: \lstinline and \usepackage{bigfoot}. This used to work before ⇒ regression. As I wrote, I don't agree. We

Re: #9785: lstinline in footnotes

Le 26/10/2015 20:52, Georg Baum a écrit : Guillaume Munch wrote: Dear Uwe, Keywords regression removed Status changed from assigned to closed Resolution set to wontfix Milestone 2.2.0 deleted I don't think that we should support things that break compilation with the default set

Re: Changebar module file

Le 01/11/2015 23:01, Jean-Marc Lasgouttes a écrit : Le 01/11/15 23:48, Guillaume Munch a écrit : List, is the attached correct? I'd say yes. I do not like much the extra redefinition, but the only other solution is plain \def. BTW, as it is implemented here, if it works reliably, this

Re: Changebar module file

Le 01/11/2015 23:01, Jean-Marc Lasgouttes a écrit : Le 01/11/15 23:48, Guillaume Munch a écrit : List, is the attached correct? I'd say yes. I do not like much the extra redefinition, but the only other solution is plain \def. BTW, as it is implemented here, if it works reliably, this

Re: Changebar module file

List, is the attached correct? >From 7879b81f3cd9fccdaa2dd16caa2e4e145753fd0a Mon Sep 17 00:00:00 2001 From: Guillaume Munch Date: Sun, 1 Nov 2015 22:30:38 + Subject: [PATCH] Module for the changebar package Author: Paul A. Rubin (ru...@msu.edu), based on code proposed by Juer

callgrind

I have added instructions for using callgrind here: . It records function calls and lets you explore them hierarchically. I found callgrind very useful for understanding how LyX works, not just for profiling. Unlike other profilers, it works without

#9785: lstinline in footnotes

Dear Uwe, Keywords regression removed Status changed from assigned to closed Resolution set to wontfix Milestone 2.2.0 deleted I don't see a regression here. The point is that users insert listings via the LyX menu or a shortcut. This inserts a lstlisting environment that will not compile whe

Re: Minimum compiler version

Vincent van Ravesteijn wrote: I thought we always wanted to support as many compilers as reasonably possible in order to allow newcomers to easily compile LyX and to let them contribute. Please, take also into account other factors determining the attractiveness to newcomers, such as switchi

Re: Bug in math macro preview

Le 24/10/2015 17:17, Guy Rutenberg a écrit : Hi, I've encounter a minor bug in the previewing of math macro: That is, after you create a math macro it would normally exapand the macro in normal math mode to the LyX representation of the macro. However, if the macro name is a single digit (e.g. \

Re: Changebar module file

Le 25/10/2015 15:37, Paul A. Rubin a écrit : Pavel Sanda lyx.org> writes: This would be nice to have, though I am wondering whether such feature doesn't belong directly to menu, next to 'Show changes in output'. More work, I know... I was hoping it would be a menu choice in an upcoming rele

Re: Changebars

Le 24/10/2015 01:09, Paul A. Rubin a écrit : This looks good except that you should use "Require changebar" instead of \usepackage{changebar}. But I am not an expert for layout files for please send it to the list so others can comment. I thought "Require ..." was for requiring a LyX module;

Re: Minimum compiler version

Le 23/10/2015 20:34, Vincent van Ravesteijn a écrit : Op 23-10-2015 om 21:22 schreef Guillaume Munch: Le 23/10/2015 20:16, Vincent van Ravesteijn a écrit : Op 23-10-2015 om 20:55 schreef Guillaume Munch: Le 23/10/2015 17:55, Peter Kümmel a écrit : I wonder to still see auto_ptr: https

Re: Minimum compiler version

Le 23/10/2015 20:27, Stephan Witt a écrit : Am 23.10.2015 um 20:55 schrieb Guillaume Munch : Le 23/10/2015 17:55, Peter Kümmel a écrit : I wonder to still see auto_ptr: https://travis-ci.org/syntheticpp/lyx Which old compiler you wanna support? Peter Dear Peter, See <h

Re: Minimum compiler version

Le 23/10/2015 20:22, Guillaume Munch a écrit : Le 23/10/2015 20:16, Vincent van Ravesteijn a écrit : Op 23-10-2015 om 20:55 schreef Guillaume Munch: Le 23/10/2015 17:55, Peter Kümmel a écrit : I wonder to still see auto_ptr: https://travis-ci.org/syntheticpp/lyx Which old compiler you wanna

Re: Minimum compiler version

Le 23/10/2015 20:16, Vincent van Ravesteijn a écrit : Op 23-10-2015 om 20:55 schreef Guillaume Munch: Le 23/10/2015 17:55, Peter Kümmel a écrit : I wonder to still see auto_ptr: https://travis-ci.org/syntheticpp/lyx Which old compiler you wanna support? Peter Dear Peter, See <h

Re: Changebars

Le 23/10/2015 16:55, Paul A. Rubin a écrit : Hi all, Is there any plan afoot to incorporate changebars in the output (when change tracking and show changes in output are enabled) in a forthcoming version of LyX? I've cobbled together a module for it (public repo at https://gitlab.msu.edu/LyX/ch

Re: Update on the patches

Le 23/10/2015 09:54, Jean-Marc Lasgouttes a écrit : Le 20/10/2015 19:23, Guillaume Munch a écrit : http://www.emacswiki.org/emacs/SmartTabs Indeed, thanks. Do you use it? JMarc Not yet because it does not seem straightforward to install here, but I am convinced that Georg's soluti

Re: Minimum compiler version

Le 23/10/2015 17:55, Peter Kümmel a écrit : I wonder to still see auto_ptr: https://travis-ci.org/syntheticpp/lyx Which old compiler you wanna support? Peter Dear Peter, See and subsequent messages. The only concrete exa

Re: Form is function

Le 20/10/2015 20:47, Liviu Andronic a écrit : I think #1 is more or less what we have now, slightly simplifying the way we roll milestones (into the .x stack) or drop milestones altogether ("very" old .x reports can be safely decommissioned). #2 will allow to much better keep track of "important

Re: Exception (basic_string) when saving on OSX.

Le 21/10/2015 06:44, pdv a écrit : I've been experiencing several exceptions on OSX, using commit 96f64ac0. Sofar I've tracked down one of them: A (basic_string) exception occurs when saving a document with a sufficient long filename (more than about 18 characters without the extension). Take an

Re: Update on the patches

Le 09/10/2015 22:07, Jean-Marc Lasgouttes a écrit : Le 09/10/2015 22:06, Georg Baum a écrit : Even more interesting. I always thought that LyX uses the "use tabs for logical indentation, and spaces for visual alignment" model for C++ code. This way, it does not matter at all whether you display

Re: [LyX/master] Add math cell positions to TexRow

Le 20/10/2015 00:42, Scott Kostyshak a écrit : On Tue, Oct 20, 2015 at 12:24:24AM +0100, Guillaume Munch wrote: In order to try to compile the file I believe you need to have R installed. Do you have R installed? If not, are you interested in installing it to debug this? I could explain how on

Re: [LyX/master] Add math cell positions to TexRow

Le 19/10/2015 23:58, Scott Kostyshak a écrit : On Mon, Oct 19, 2015 at 07:56:13AM +0200, Guillaume Munch wrote: commit 65d61e7a2786172da95ed9433ed0c49a7398f405 Author: Guillaume Munch Date: Wed Oct 14 00:17:05 2015 +0100 Add math cell positions to TexRow This is preliminary work

Re: LyX's master is now uncompilable

Le 19/10/2015 22:01, Georg Baum a écrit : Guillaume Munch wrote: The former. If we are supposed to include support/docstream.h to use odocstringstream, shouldn't the latter be defined in docstream.h instead of strfwd.h? (or the fix be moved to strfwd.h which is already included by docstr

Re: LyX's master is now uncompilable

Le 19/10/2015 21:59, Vincent van Ravesteijn a écrit : Op 19 okt. 2015 22:51 schreef "Guillaume Munch" mailto:g...@lyx.org>>: > > Le 19/10/2015 21:34, Georg Baum a écrit : >> >> >> The message on the list is related to commit e948caf6, which is suppos

Re: [patches] the last ones before 2.2

Le 19/10/2015 20:57, Georg Baum a écrit : I archive this in a bug report? Yes please. http://www.lyx.org/trac/ticket/9804

Re: LyX's master is now uncompilable

Le 19/10/2015 21:34, Georg Baum a écrit : The message on the list is related to commit e948caf6, which is supposed to fix exactly this issue. What I do not understand it why the fix does not work for your recent changes. Maybe you forgot to include docstream.h somewhere or got the include order

Re: [patches] the last ones before 2.2

Le 19/10/2015 20:32, Georg Baum a écrit : Guillaume Munch wrote: The choice is simple, because just adding a new variable member to math insets as per the attached (trivial) .diff leads to new segfaults with math macros. The .diff must be applied to current master (before or after my upcoming

Re: [LyX/master] msvc: Fix compilation of TexRow

Le 19/10/2015 20:28, Vincent van Ravesteijn a écrit : commit 10d7f6d479b05cf101173a8ab036676482b7c251 Author: Vincent van Ravesteijn Date: Mon Oct 19 21:25:26 2015 +0200 msvc: Fix compilation of TexRow The problem was that "odocstringstream << (const char *) ptr" did not compi

Re: Many tex2lyx failing now on master

Le 19/10/2015 19:55, Scott Kostyshak a écrit : It could be. Please do not spend any time on this right now though. Let's first see if Uwe has an idea of how to fix them. Just making sure I'm not responsible for breaking things again :)

Re: Many tex2lyx failing now on master

Le 19/10/2015 19:12, Scott Kostyshak a écrit : Many tex2lyx tests have started to fail (before it was just 4 and we knew why and I think Günter's recent commit might have fixed them?). Now 14 are failing. Scott I would have liked to help with tests, but when I tried to run "make alltests" b

Re: [LyX/master] Adding TexRow information on math latex output (#4725)

Le 19/10/2015 17:58, Jean-Marc Lasgouttes a écrit : Le 19/10/2015 17:31, Guillaume Munch a écrit : The next thing that we need for line tracking is Sweave support; sweave does rewrite some parts of the document, and therefore the line numbers are not accurate anymore. It is however possible to

Re: LyX's master is now uncompilable

Le 19/10/2015 16:50, Uwe Stöhr a écrit : Am 19.10.2015 um 16:14 schrieb Uwe Stöhr: one of todays' commits broke the compilation for me with MSVC: C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xstring(982): error C2491: 'std::numpunct<_Elem>::id': Definition of static data me

Re: LyX's master is now uncompilable

Le 19/10/2015 15:14, Uwe Stöhr a écrit : Dear LyXers, one of todays' commits broke the compilation for me with MSVC: C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xstring(982): error C2491: 'std::numpunct<_Elem>::id': Definition of static data member for dllimport is not allo

Re: [LyX/master] Adding TexRow information on math latex output (#4725)

Le 19/10/2015 14:37, Jean-Marc Lasgouttes a écrit : Le 19/10/15 15:07, Pavel Sanda a écrit : Guillaume Munch wrote: This finishes adding line tracking for math in the source panel and for forward search. Sweet :) Thanks. Next step is rewrite the algorithm for error reporting and

Re: [patches] the last ones before 2.2

Le 19/10/2015 09:54, Jean-Marc Lasgouttes a écrit : Le 15/10/15 19:32, Guillaume Munch a écrit : Jean-Marc's comment seems to be: sometimes we would like the id to remain the same (which indeed would not be taken into account by the current patch). Jean-Marc, did I understand you r

Re: [patches] the last ones before 2.2

Le 17/10/2015 21:19, Guillaume Munch a écrit : Le 17/10/2015 15:13, Richard Heck a écrit : On 10/16/2015 12:34 PM, Guillaume Munch wrote: The id is now only on InsetMathNest. Please, tell me if you still feel uncomfortable about this id and I will try a version with pointer comparison. This

Re: [patches] the last ones before 2.2

Le 17/10/2015 12:00, Georg Baum a écrit : Guillaume Munch wrote: But if the memory usage is still too high, various solutions: * pointer comparison (what is your opinion on pointer comparison vs. using a counter?) * variable-length integers encoding. * pointer comparison, but somehow keep the

Re: [patches] the last ones before 2.2

Le 17/10/2015 15:13, Richard Heck a écrit : On 10/16/2015 12:34 PM, Guillaume Munch wrote: The id is now only on InsetMathNest. Please, tell me if you still feel uncomfortable about this id and I will try a version with pointer comparison. This incremental id, I found, gives interesting clues

Re: macron below vs. minus sign below (was tex2lyx tests failing on master)

Le 17/10/2015 16:02, Guenter Milde a écrit : I see it rather as a one-time effort to get the lyx-cvs permissions right. The additional loop ("... and, btw., you need to subscribe to this list if you really want to commit") after finally getting commit rights set up and working will hit other fut

Re: [patches] the last ones before 2.2

Le 17/10/2015 12:00, Georg Baum a écrit : Sorry, I don't have the time right now to really measure, but I think it is not needed, since the numbers you got are OK IMHO. … As I see it, we do now have a trade off between easier debugging (ids), and less memory consumption (pointers). Apart from t

Re: [patches] the last ones before 2.2

Le 16/10/2015 21:52, Georg Baum a écrit : Guillaume Munch wrote: Le 14/10/2015 21:35, Georg Baum a écrit : Please measure memory consumption. I am a bit afraid that this increases memory usage a lot, since math insets contain very tiny bits of information, and you may need _lots_ of them

Re: [patches] the last ones before 2.2

Le 16/10/2015 19:57, Scott Kostyshak a écrit : On Fri, Oct 16, 2015 at 05:34:33PM +0100, Guillaume Munch wrote: Scott, I would like to commit this series of patches before α. What is the time frame? I would like to release the alpha early next week. JMarc has a pending patch. Günter has many

Re: macron below vs. minus sign below (was tex2lyx tests failing on master)

Le 16/10/2015 18:10, Guenter Milde a écrit : We are talking about a one time effort of at most half an hour for one person only. Subscribing to lyx-cvs with lyx.org addresses works in general (one could ask Guillaume how he did it if it is unclear how it works), and setting up a filter in the g

Re: [patches] the last ones before 2.2

Le 15/10/2015 18:26, Guillaume Munch a écrit : Why do you need a new member variable at all? Why can't you just use the memory address? This would not consume memory and still be a unique id. Yes, it would make sense to use pointers IMO. There was two reasons for the UniqueId class: I n

Re: lyx.org down for me

Le 16/10/2015 16:57, Scott Kostyshak a écrit : It has been unresponsive the last half-hour or so. Scott Yes, for a few hours here.

Re: [patches] the last ones before 2.2

Le 15/10/2015 18:20, Georg Baum a écrit : Jean-Marc Lasgouttes wrote: Why do you need a new member variable at all? Why can't you just use the memory address? This would not consume memory and still be a unique id. I guess that the answer is the same as for paragraph ids: they can get copied

Re: Form is function

Le 14/10/2015 09:38, Liviu Andronic a écrit : On Wed, Oct 14, 2015 at 7:55 AM, Guillaume Munch wrote: the hard truth is that our manpower is limited and our devels barely have the bandwidth to address crashes, regressions and the like (in between monitoring tickets, triaging, helping on

Re: Pixmap cache is broken for master

Le 15/10/2015 09:20, Jean-Marc Lasgouttes a écrit : Le 14/10/15 14:22, Stephan Witt a écrit : Indeed. What about just dumping it? :p I'm all for it. I did some profiling. Pixmaps are indeed a little bit faster visually. Here are the hard numbers Without Pixmaps: 66% LyX 32% GuiWorkAre

Re: IBus compatibility

Le 14/10/2015 20:00, Georg Baum a écrit : Jean-Marc Lasgouttes wrote: Le 11/10/2015 12:43, Guillaume Munch a écrit : Qt 5.6.0 will probably be released before LyX 2.2.0. Therefore the most simple solution would be to disable IBus if an older qt is detected (at runtime) and mention in the

Re: [patches] the last ones before 2.2

Le 14/10/2015 21:35, Georg Baum a écrit : *#2: Add a unique id to math insets. I also print this information in the DEVEL_VERSION in the status bar similarly to what is done currently for paragraphs. It is interesting that while the paragraph id is usually below 1, this new math inset id imm

Re: Form is function

Le 14/10/2015 07:53, Pavel Sanda a écrit : Guillaume Munch wrote: I remember putting the remark about low priority in FAQ. Here's all I could find about "enhancement" or "priority" on Trac, the website, the wiki and the repository (with git grep): ?Enhancements ha

Re: Form is function

Scott asked not long ago what could be done to make it easier for newcomers. It is now clear to me that having a clearer bug tracker is an aspect that can be improved. In addition, the initial question was to know what to do with tickets with an unmet milestone. Taking into account what has been

Re: Form is function

TL;DR: thank you for your suggestions and criticisms; new propositions in a separate message. Le 13/10/2015 02:20, Scott Kostyshak a écrit : If we do decide to get rid of the 2.2.x milestone, it is easy to do, rather than if we change our mind from getting rid of it to keeping it. Yes, than

[patches] the last ones before 2.2

o fix now, please report any problems you still encounter. Sincerely Guillaume >From 492bad9f3f3ebc6d4b3064465e82a45b015eca4b Mon Sep 17 00:00:00 2001 From: Guillaume Munch Date: Wed, 14 Oct 2015 00:17:05 +0100 Subject: [PATCH 1/8] Add math cell positions to TexRow This is preliminary work for

Re: Form is function

Le 13/10/2015 00:53, Scott Kostyshak a écrit : On Sun, Oct 11, 2015 at 10:28:23PM +0200, Liviu Andronic wrote: On Sun, Oct 11, 2015 at 4:27 PM, Guillaume Munch wrote: The problem with letting community members define what is important and what is not, is that for each and every one of us our

Re: Form is function

Le 11/10/2015 15:27, Guillaume Munch a écrit : I can apply my proposal to the Trac page right now for you to judge, and we can revert it if you are not convinced. ...essentially adding at the end of the page: [[BR]] == High priority defects == [[TicketQuery(order=id,desc=1,format=table

Re: Form is function

Le 11/10/2015 12:19, Liviu Andronic a écrit : This way .x targets are indicative of the relative recent nature of the bug, which is still useful info. It is useful to know if a bug is recent, but we already have the bug # and often the version, no? I think that Guillaumes proposal to use

Re: [LyX/master] Fix cursor movement for large logos (#9628)

Le 11/10/2015 13:26, Georg Baum a écrit : commit 359aef92f87169ce2683e287bb24bc3d5f46a190 Author: Georg Baum Date: Sun Oct 11 14:21:45 2015 +0200 Fix cursor movement for large logos (#9628) Previously, if one clicked onto a large non-editable inset like the new LyX logo inset,

<    3   4   5   6   7   8   9   >