Re: \input@path - two slashes, quotation marks

2015-08-05 Thread PhilipPirrip
Did a little research. \input@path is in src/Buffer.cpp, but since 2.0.1 
another method has been introduced /see below/.

It, however, doesn't seem to work for biber, no .bib files are found.
So, any idea why \input@path exports, or should export
{"/home/user/dir ecto ry"/}
instead of simple
/home/user/dir ecto ry/




src/Buffer.cpp:
os << "\\makeatletter\n"
   << "\\def\\input@path{{"
   << docdir << "/}}\n"
   << "\\makeatother\n";




What's new in version 2.0.1?

We would like to highlight the improved handling of external files 
referenced from ERT. This may cause issues for those who made use of the 
undocumented \input@path hack. See the ANNOUNCE file again for how to do 
things the new way. New methods for calling external scripts should also 
solve several issues on Windows.




What's new in LyX 2.0.1
===
The support for using external files in ERT has been improved by the
introduction of a prefix for the TEXINPUTS environment variable.
This prefix can be set in preferences and by default includes the
document directory (represented by a single '.'). The prefix can
be set to any list of paths separated by the default separator for
a given platform (':' on unix like systems and ';' on windows).
When a file should be included by LaTeX, the paths listed in TEXINPUTS
will be searched in turn for finding it. Note that any non-absolute
path listed in the TEXINPUTS prefix is considered to be relative to the
document directory, i.e., the directory where the LyX file lives.
Users are advised to always include '.' (the document dir) as one of
the path components, otherwise compilation may fail for some documents.
This is because the previous (undocumented) mechanism based on the use
of the \input@path macro has been dropped. The old mechanism did not
work in all cases and was kind of a hack. Old documents using that
undocumented hack for obtaining the path of the LyX file will have to
be revised. A clean way for obtaining the document path is using the
info inset through the "info-insert buffer path" LyX function.



On 08/04/2015 02:39 PM, PhilipPirrip wrote:

Why does \input@path end with two slashes, as in
/home/user/directory//
and why is its output
"/home/user/dir ectory/"/
(note quotation marks, and two separate ending slashes) when the folder
name contains spaces?







Re: [PATCH] \{ and \% now correctly use the selection as their argument instead of erasing it (bug #6466)

2015-08-05 Thread Richard Heck

On 08/03/2015 09:32 AM, Guillaume Munch wrote:

Le 31/07/2015 17:05, Guillaume Munch a écrit :

\{ and \% now correctly use the selection as their argument instead of
erasing it. Solves . Please 
criticise.





If there are no experts of math mode 


I think the main problem here is that it is August, and a lot of people 
are away.


to review the patch, here's to help you check: 1) the change to 
InsetMathNest.cpp is inspired from existing code in Cursor.cpp:1542, 
2) the new constructor in InsetMathComment is copied from 
InsetMathBrace (that's all).


While writing that I noticed that I forgot one line from Cursop.cpp 
(p->finalize()), here's the amended version.


Otherwise, I suspect this is fine. You need someone to commit for you?

Richard




Re: [PATCH] minor improvements to mathed

2015-08-05 Thread Richard Heck

On 08/01/2015 06:34 AM, Guillaume Munch wrote:

Here are again two very small patches if you agree.

1. Add \ensuremath to the list of math completions.


This is certainly fine.


2. math-mode inserts \text instead of \mbox when already in math mode.

For the latter, \mbox is meant as a way to switch to text mode, but 
\text from amstext is more appropriate for this purpose. This forces 
amstext to be automatically included, but we already include 
automatically amstext for \textrm, \textit, etc. even though it's not 
required.


Uwe, do you have a view about this?

Also, a bug: I noticed that the "Insert regular expression" menu is 
always visible in master (+qt5) even though it's only useful for 
Advanced search (afaik). Is this on purpose?


Probably not.

Richard