Re: [coverity again] missing move constructors

2017-05-23 Thread Scott Kostyshak 
On Tue, May 09, 2017 at 04:25:15PM +0200, Jean-Marc Lasgouttes wrote:
> Le 21/04/2017 à 00:11, Guillaume MM a écrit :
> > Le 08/04/2017 à 23:05, Jean-Marc Lasgouttes a écrit :
> > > 
> > > > FileName:
> > > > This would be automatically copyable and movable if not for the use of
> > > > the pointer to implementation.
> > > 
> > > What is the problem with the pointer?
> > 
> > For motivations see for instance
> > .
> 
> The spimpl template declared there looks good to me. There is no problem
> with distributing Boost licenced stuff with LyX, we do it already.
> 
> Concerning the patches, thery are in general way above my head, and I trust
> your judgment. My remarks are
> * it is not nice to have to use unique_ptr allover the place, I
> do not really care about implementation details. Is it possible to have the
> vector carry InsetLabel objects instead?
> * the MouseHover.* files seems to be missing fro your third patch.
> 
> > Speaking of review, I found that setMouseHover was never used, making
> > the variable useless. What do you think?
> 
> I'm afraid I don't understand what you mean here.

Guillaume, do you feel confident enough to push these patches for 2.3.0?
Or since there is no performance gain, do you think it's best to not
have them in 2.3.0 at this point? It's your call.

Scott


signature.asc
Description: PGP signature

Re: Fix for vertical table border for added column

2017-05-23 Thread Scott Kostyshak 
On Sun, May 07, 2017 at 03:31:30PM +0200, Guillaume MM wrote:
> Le 15/02/2017 à 04:24, Scott Kostyshak a écrit :
> > On Tue, Oct 18, 2016 at 11:03:21PM +0200, racoon wrote:
> > > On 18.10.2016 21:35, racoon wrote:
> > > > I think the attached fix leads to more intuitive results for added table
> > > > borders.
> > > > 
> > > > This solves one strange case:
> > > > 1. create a new table (with the default borders, in particular the last
> > > > row has the borders |c|)
> > > 
> > > column not row I meant.
> > > 
> > > > 2. add a column after the last most right) column
> > > > 
> > > > Actual result:
> > > > - The last two rows have the borders |c||c
> > > 
> > > Same here. Need sleep. :)
> > > 
> > > 
> > 
> > Hi racoon,
> > 
> > Is this patch still pending? If so, I can take a look at it.
> > 
> 
> Same question here.

CC'ing racoon directly.

Scott


signature.asc
Description: PGP signature

Re: ext_copy.py

2017-05-23 Thread Scott Kostyshak 
On Thu, May 04, 2017 at 11:44:05PM -0400, Richard Heck wrote:
> On 05/04/2017 07:15 PM, Andrew Parsloe wrote:
> > I would like to see the following small change made to the script
> > ext_copy.py for 2.3.0:
> >
> > Currently it contains the lines:
> >
> > # output directory
> > to_dir = args[1]
> > if targext != '.':
> > to_dir += "." + targext
> >
> > Change this to
> >
> > # output directory
> > if targext == '+':
> > to_dir = os.path.dirname(args[1])
> > else:
> > to_dir = args[1]
> > if targext != '.':
> > to_dir += "." + targext
> >
> > With the change, by using the option -t + this allows a file to be
> > copied back to the document directory at the same level and not
> > 'buried' in a subdirectory. Some years ago I asked about this and
> > Richard explained the need to use a subdirectory to prevent the
> > document directory being swamped by sundry files from html export. But
> > there are other use cases. I have one in which a single file is copied
> > back. Not to be able to place it directly in the document directory
> > seems an arbitrary and unnecessary restriction. With my proposed change
> >
> > python -tt $$s/scripts/ext_copy.py -e lyxdat -t + $$i $$o
> >
> > copies .lyxdat back to the home directory of .lyx.
> > Without the + option, ext_copy.py behaves as before. (Whether + is an
> > appropriate character is moot. The natural one would perhaps be . but
> > that is already used.)
> 
> No objection from me.

Any objection from anyone else?

Scott


signature.asc
Description: PGP signature

Re: Lyx 2.2 errors w/ miktex 2.9.6 (on win10)

2017-05-23 Thread Scott Kostyshak 
On Wed, Apr 19, 2017 at 11:29:12AM +0200, Jean-Marc Lasgouttes wrote:
> Le 17/04/2017 à 00:47, Cris Fuhrman a écrit :
> > Another problem I encounter is with long file paths, but only when
> > using, say, PNG images in my LyX files. LyX again fails with an obscure
> > error. Debugging the image conversion in the cache showed that my the
> > filename was really long and at some point the converted image was "not
> > found". I moved my LyX file directory to a path closer to the root, thus
> > making the cache file names shorter, and the errors stop. I can probably
> > reproduce this easily, if more info is needed.
> 
> I am not really sure why we use such long temp file names. What's the
> benefit, since the leading index makes sure that the file is unique? Why is
>   1_my_long_path_for_some_unknown_reason_file.png
> better than
>   1_file.png
> ?
> 
> I understand that this gives minor debugging information (that can probably
> be obtained via a debugging channel), but it is not the first time that it
> triggers LaTeX file length limits.

Chris, do you feel like writing up a bug/enhancement request at

https://www.lyx.org/trac

? A reproducible example would indeed give us a push to look into an
improvement.

Scott


signature.asc
Description: PGP signature