Re: Update on the patches

Le 01/10/2015 00:43, Pavel Sanda a écrit : Jean-Marc Lasgouttes wrote: Le 15/09/2015 17:54, Guillaume Munch a écrit : I can remove more irrelevant parts and do that, but before that I am hoping to get some better configuration if anybody else is using emacs. BSD is just close to your style

Re: 2 compilation errors with current master

Le 30/09/2015 17:18, Jean-Marc Lasgouttes a écrit : Le 30/09/2015 18:08, Guillaume Munch a écrit : Surely more difficult than my patch. Also it's pointless spending too much effort since support/shared_ptr.h will disappear in 2.3. Yes, but I dislike solutions that require to check com

Re: [PATCH] Improvements to cursor highlighting in the source panel

Le 30/09/2015 13:20, Jean-Marc Lasgouttes a écrit : Le 28/09/2015 19:51, Guillaume Munch a écrit : Then it would make my life easier in improving TexRow to support such argument insets because the latex error reporting is more precise. Also, this could just be an option which would be enabled

Re: #9759: "List of figures" navigation menu is not convenient

Le 28/09/2015 19:56, Jürgen Spitzmüller a écrit : Am Montag 28 September 2015, 04:11:37 schrieb Guillaume Munch: The attached patch includes the above features along with other enhancements like a symbol that indicates disabled entries. (See description.) OK to commit? Looks very good. Thanks

Re: Understanding the painting process (André, Abdel, Lars, please read)

Le 02/10/2015 14:38, Jean-Marc Lasgouttes a écrit : Hello, Hello After a gentle push by Guillaume and a boring meeting, I decided to actually read the code that handles metrics computing and contents drawing. The result is the document below, which is available in development/PAINTING_ANALIS

UTF-8 in string literals and translation strings in particular

Deal list, Has there been some discussion already about allowing UTF-8 in the source code, in particular for translatable strings? Is this something we long for? Guillaume

Re: LyX on high resolution displays

Le 05/10/2015 12:38, PhilipPirrip a écrit : Hi, It is pretty bad that 2.2 is slower than 2.1. Could you share your lorem ipsum document? JMarc Hi JMarc, It was a plain text lorem ipsum copied from the web to a text editor and then to LyX, nothing special about it. It had paragraphs of some 6-

Re: [LyX/master] Fix compilation with MSVC in c++98 mode

Le 05/10/2015 00:56, Uwe Stöhr a écrit : Am 01.10.2015 um 23:10 schrieb Guillaume Munch: commit 39343d65af804d83803b16557b624f3cc024cc21 Author: Guillaume Munch Date: Mon Sep 28 18:13:19 2015 +0100 Fix compilation with MSVC in c++98 mode Hello Guillaume, welcome on board of LyX

Re: UTF-8 in string literals and translation strings in particular

Le 04/10/2015 23:20, Guillaume Munch a écrit : Dear list, Has there been some discussion already about allowing UTF-8 in the source code, in particular for translatable strings? Is this something we long for? Guillaume Seeing how there is unanimous interest, here's a proof of co

Re: segmentation fault, lyx2.2.0dev @ Fedora 23 with Qt 5.5.0

Le 06/10/2015 15:29, Kornel Benko a écrit : Hi Kornel, I could send it if I knew how. Sorry, have no experience with that, but willing to learn! # gdb lyx Or as I learnt recently, to properly see the symbols (you'll have to compile with the various devel options ON though): # li

Re: UTF-8 in string literals and translation strings in particular

Le 06/10/2015 17:13, Pavel Sanda a écrit : Guillaume Munch wrote: Le 04/10/2015 23:20, Guillaume Munch a écrit : Dear list, Has there been some discussion already about allowing UTF-8 in the source code, in particular for translatable strings? Is this something we long for? Guillaume

Re: UTF-8 in string literals and translation strings in particular

Le 06/10/2015 18:28, Jean-Marc Lasgouttes a écrit : Le 06/10/2015 18:38, Guillaume Munch a écrit : I'm trying to come up with examples where do we actually "need" unicode in the interface. The ellipsis case seems to be trivial indeed. Is it trivial? On my ubuntu libreoffi

Re: UTF-8 in string literals and translation strings in particular

Le 06/10/2015 18:28, Jean-Marc Lasgouttes a écrit : For the docstring part of the code, I am not sure what code like the following do: -LASSERT(static_cast(*c) < 0x80, return l); -s.push_back(*c); +if (static_cast(*c) < 0x80) +s.push_back(*c); +else +return s +=

Re: UTF-8 in string literals and translation strings in particular

Le 06/10/2015 20:03, Guillaume Munch a écrit : Le 06/10/2015 18:28, Jean-Marc Lasgouttes a écrit : For the docstring part of the code, I am not sure what code like the following do: -LASSERT(static_cast(*c) < 0x80, return l); -s.push_back(*c); +if (static_cast(*c) <

Re: UTF-8 in string literals and translation strings in particular

Le 06/10/2015 21:01, Pavel Sanda a écrit : Guillaume Munch wrote: Seriously, I think this is just going to annoy our translators. Seriously :) as described in the rationale of my patch, this cannot be more transparent for translators. Gettext pre-sets the previous translation; translators

Re: UTF-8 in string literals and translation strings in particular

Please, do not scatter the messages that much, and make the discussion easy to follow. Recalling the subject of the discussion: Le 08/10/2015 01:55, Cyrille Artho a écrit : Why not apply a variant of that hack as using "sed" to all the language/menu strings in the repository? Of course the c

Re: segmentation fault, lyx2.2.0dev @ Fedora 23 with Qt 5.5.0

Le 06/10/2015 15:41, PhilipPirrip a écrit : Thanks, Kornel. I'll check these later. I went back in time, September 28 18:13 commit 39343d65af worked. Moving forward, will let you know when things went bad and send you the backtrace. Dear Philip, I cannot reproduce it with my own document

Re: segmentation fault, lyx2.2.0dev @ Fedora 23 with Qt 5.5.0

Le 08/10/2015 15:27, PhilipPirrip a écrit : Dear Guillaume, I finished my search for the bug yesterday, by checking out a few suspicious commits in the last 30 days, and to my great surprise even the latest commit worked. I really don't know what happened. I had it all built in a separate directo

Re: UTF-8 in string literals and translation strings in particular

Le 08/10/2015 14:45, Jean-Marc Lasgouttes a écrit : I will reply only to some of the arguments for the sake of efficiency. As we usually say, I lacked the time to make it shorter... The problem with the patch is that it does not have a clear goal. The discussion would have been much easier i

Re: UTF-8 in string literals and translation strings in particular

Le 08/10/2015 16:46, Kornel Benko a écrit : Am Donnerstag, 8. Oktober 2015 um 16:14:49, schrieb Stephan Witt I think the idea was to let the translators do it manually where it is appropriate. And to do it for english this way too. I think that too. I did it for sk.po, it looks OK to me. No

Re: UTF-8 in string literals and translation strings in particular

Le 08/10/2015 22:11, Georg Baum a écrit : Jean-Marc Lasgouttes wrote: The problem with the patch is that it does not have a clear goal. The discussion would have been much easier if you had splitted it in 3 from the start: 1/ easy use of utf8 in docstring 2/ allow utf8 in translattable strings

Re: Moving towards a 2.2 release

Le 10/10/2015 05:01, Scott Kostyshak a écrit : 1. Do you agree that the master branch is stable and that we should move soon towards releasing an alpha? I saw a couple of reports of crashes that could not be reproduced (Guillaume, I think you had one recently? [1]), but these seem to be the norm

Form is function (was: Removing 2.2.0 milestone (as opposed to changing to 2.3.0))

Le 10/10/2015 22:51, Scott Kostyshak a écrit : I am going to start removing many 2.2.0 milestones if it seems unlikely the bugs will be fixed for 2.2.0 (i.e. no one has said they are working on them). If I remember correctly, there was some discussion on this and most LyX developers prefer this (

Re: Moving towards a 2.2 release

Le 10/10/2015 23:25, Scott Kostyshak a écrit : On Sat, Oct 10, 2015 at 07:50:59PM +0100, Guillaume Munch wrote: http://www.lyx.org/trac/ticket/9362 : the problem has been quite precisely identified, a decision has to be taken. Even if it is just "let's warn the users".

Re: IBus compatibility

Le 29/09/2015 02:23, Guillaume Munch a écrit : The bug <http://www.lyx.org/trac/ticket/9362> causes the keyboard to malfunction and consistently causes deadlocks with data loss. I've finally narrowed down the issue to the fact that LyX is currently incompatible with IBus and in par

Re: IBus compatibility

Le 11/10/2015 10:32, Georg Baum a écrit : Guillaume Munch wrote: Decision has to be taken about the keyboard issues and deadlock in <http://www.lyx.org/trac/ticket/9362> under Linux with IBus. The issue is going to be solved by Qt5, but unfortunately due to <http://www.lyx.org/tr

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,

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

[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

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

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

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: [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: 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: 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: 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: [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: 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: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: 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 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: [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 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: 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 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: [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 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 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: [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: 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'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/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: 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: 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: [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: [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'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: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: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: 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/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/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: 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: 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: 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: 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: 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: 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: 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: 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: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: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: 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: 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: 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: 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

#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

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

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

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

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

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

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 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: [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: [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: [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: [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: [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 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: [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: #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: #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 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

<    1   2   3   4   5   6   7   8   9   >