Re: build particular release version from git

2018-10-19 Thread Richard Kimberly Heck
On 10/19/18 6:57 PM, Majzoub, Eric wrote:
> Hello,
>
> Two questions:
>
> 1. I have been building Lyx from the git repository and choosing a
> particular branch, (e.g. git checkout 2.3.x). But when a release is
> made I would like to build the released version from git, and not the
> new commits that have been made to the branch. How do I check out a
> particular release version to build from?

The releases are always tagged with the version number. (Use "git tag"
to see all the tags.) You can check these out the same way you would
check out a branch, e.g., "git checkout 2.3.1".

For what it's worth, I always use 2.3.x (or whatever stable currently
is) for actual work. Then I get the latest bug fixes (though on the
other side also any regressions that may have been introduced). Of
course, that's partly because I'm a developer, but it's VERY helpful to
us if people use (and so test) 2.3.x.


> 2. What are the "staging" branches? e.g. 2.3.1-staging,  2.3.2-staging, 
> etc.

They were branches used to collect commits intended for e.g. 2.3.1
before 2.3.0 was released. I should delete them.

Riki




build particular release version from git

2018-10-19 Thread Majzoub, Eric
Hello,

Two questions:

1. I have been building Lyx from the git repository and choosing a
particular branch, (e.g. git checkout 2.3.x). But when a release is
made I would like to build the released version from git, and not the
new commits that have been made to the branch. How do I check out a
particular release version to build from?

2. What are the "staging" branches? e.g. 2.3.1-staging,  2.3.2-staging, 
etc.

Many thanks for any advice.


Re: An observation on 3.2.1 spell checking

2018-10-19 Thread Paul A. Rubin

On 10/18/18 4:26 PM, Rich Shepard wrote:
The document I'm now writing has many hyphenated words (e.g., 
Douglas-fir,
near-surface) and all are questioned by the spelling checker. I don't 
recall
seeing this before and don't know if its source is lyx or the spell 
checker

being used (I don't recall whether it's aspell or ispell).

  No action is required on anyone's part but I find it interesting that
these compound words are seen as being mis-spelled, even after I
(supposedly) add them to the dictionary.

Regards,

Rich
LyX is not the culprit. I just copied your first paragraph into a LyX 
document (and added a hyphenated word of my own, in case the hyphens in 
your email pasted in as some funky character). The spelling checker 
(Enchant, which probably means aspell doing the actual work) had no 
problem with any hyphenated words. It only bitched about "lyx" and 
"aspell" (but, curiously, not about "ispell").


Perhaps it's a configuration option in whichever engine you're using? If 
that's too much hassle, you might try going to Tools > Preferences... > 
Language Settings > Spellchecker and putting a hyphen in the "Escape 
characters" field. Maybe that will fix it?


Paul



Re: Exporting as PDF (cropped) is not cropping

2018-10-19 Thread Paul A. Rubin

On 10/19/18 5:54 AM, list_em...@icloud.com wrote:

When I open a new document, type an equation, and export as PDF (cropped), I 
expect to see a PDF file that has zero extra white space around the graphical 
portion of the math. Instead, I see an entire page with the equation on the 
first line. I.e., no cropping. What am I doing wrong?

LyX 2.3.0

Jerry
When you say "entire page", do you mean a full page in both dimensions? 
I just tried it, and I got a PDF with a full page (including page 
number) in the vertical dimension but a width just barely enough to hold 
the equation.


If you need cropping in both directions, I would suggest using the 
"standalone" document class. If the equation is inline, that should be 
sufficient. If the equation is display mode (centered on the page), you 
can either (a) convert it to inline and switch to display mode for 
subscripts and superscripts inside the inline equation (then export 
normally, no cropping required), (b) leave the equation in display mode 
and add the "preview" class option, then export normally, or (c) do (b) 
but export cropped. Methods (a) and (c) should produce an equation with 
minimal whitespace on any side; method (b) will (I think) crop 
vertically but not horizontally.


Paul


Re: LyX 2.3.1 -- Beamer presentation

2018-10-19 Thread F M Salter
Hi,

    Thanks to Daniel, I rectified the problem.

Regards

Frank Salter



Re: you say install latest version of MiKTeX before installing LyX - what is the minimal version needed?

2018-10-19 Thread Kees Zeelenberg

Op 13-10-18 om 19:58 schreef Paul Johnson:

The only critical flaw in TeXLive we have encountered is that it does
not include texi2pdf. Because of that absence, the R team is still
devoted to MikTeX as a part of the tool chain to build/use R for
windows. I spent a while trying to figure out how to compile texi2pdf
on Windows and gave up. (It appears to me the efforts to make open
source things work on windows are fraught with danger. The Windows
test system here has 5 or 6 different Cygwin-based installations and
the path is a tangled web of incompatible libraries and executables.
Sorry, that's just a Unix guy in foreign territory whining.)


texi2pdf is a script around makeinfo. MikTeX does not have texi2pdf / 
makeinfo either. Probably MikTeX is used because it has texify. It is 
true that texify is able to call makeinfo. But from looking at the 
source at https://github.com/MiKTeX/miktex, it appears that it does this 
only if a certain option for that is given on the command line of 
texify; and if makeinfo is then not available,  texify quits.


So it might well be that what texify actually does, is to run latex, 
bibtex etc. several times; and for that it is indeed very handy. There 
may be an alternative for this in TeXLive or elsewhere. If not, then it 
would probably be quite easy to compile texify. In any case, its source 
code is GPL.


As far as I recall, texipdf / makeinfo is only needed for documents 
written in an older version of the TeXInfo format. But if it is really 
needed, then it is easy to compile for Windows, since from the sources 
at GnuWin32, it appears that it compiles without changes on Windows, 
with the mingw compiler or with the VisualC++ compiler. It is even 
easier to compile on Linux with a cross compiler for Windows; so no need 
for Cygwin.


Kees




Re: An observation on 3.2.1 spell checking

2018-10-19 Thread Jean-Marc Lasgouttes

Le 19/10/2018 à 15:05, Rich Shepard a écrit :

   I just looked at the SlackBuild script I've used for years (chaning only
version numbers) and see nothing related to spell checkers in the configure
section so I assume that all but ispell are in included.


It depends actually of what development packages (header files) are 
available when configuring.


JMarc


Re: An observation on 3.2.1 spell checking

2018-10-19 Thread Rich Shepard

On Fri, 19 Oct 2018, Jean-Marc Lasgouttes wrote:


ispell is the one for oldtimers.
aspell is the more modern ispell.
hunspell is the more modern aspell
enchant is a wrapper that canbe configured at system level to use whatever 
spell checker you have on your system (not sure where).


JMarc,

   Thanks very much for the insight. I've not before paid any attention to
this.


It depends on what spell checkers have been compiled in when building LyX.


  I just looked at the SlackBuild script I've used for years (chaning only
version numbers) and see nothing related to spell checkers in the configure
section so I assume that all but ispell are in included.

  Interesting detail.

Best regards,

Rich


Re: An observation on 3.2.1 spell checking

2018-10-19 Thread Jean-Marc Lasgouttes

Le 19/10/2018 à 14:33, Rich Shepard a écrit :

   Turns out lyx was set to use enchant (never knew of this before) where I
used to use aspell or ispell. (Here, aspell, enchnat, ispell, and hunspell
are all installed and I've no idea how, or why, they differ.)


ispell is the one for oldtimers.
aspell is the more modern ispell.
hunspell is the more modern aspell
enchant is a wrapper that canbe configured at system level to use 
whatever spell checker you have on your system (not sure where).


 Anyway, I was

offered aspell as an option so I changed the spell checker to that. The
option, 'accept compound words' was checked yet apparently not available in
enchant. Because this non-acceptance was a chenge from the past lyx must
have changed the default spell checker in a recent upgrade and I hadn't
noticed. Probably because I didn't go looking for the reason.


It depends on what spell checkers have been compiled in when building LyX.

JMarc


Re: Exporting as PDF (cropped) is not cropping

2018-10-19 Thread Rich Shepard

On Fri, 19 Oct 2018, list_em...@icloud.com wrote:


When I open a new document, type an equation, and export as PDF (cropped),
I expect to see a PDF file that has zero extra white space around the
graphical portion of the math. Instead, I see an entire page with the
equation on the first line. I.e., no cropping. What am I doing wrong?


Jerry,

  How about providing a minimal working example?

  Is the equation the only line in the document? Is it an inline or display
equation? What other characteristics are selected on the Insert -> Math
menu?

  The more details the better.

Regards,

Rich


Re: An observation on 3.2.1 spell checking

2018-10-19 Thread Rich Shepard

On Fri, 19 Oct 2018, Daniel wrote:


Those words are not marked on my system. I use Hunspell on Windows (which
is installed as default with LyX, I think). You can check your
spell-checker via

Preferences > Language Settings > Spellchecker


Daniel,

  Well, well, well! I don't recall ever looking at that portion of settings
in the many years I've used lyx (all on linux).

  Turns out lyx was set to use enchant (never knew of this before) where I
used to use aspell or ispell. (Here, aspell, enchnat, ispell, and hunspell
are all installed and I've no idea how, or why, they differ.) Anyway, I was
offered aspell as an option so I changed the spell checker to that. The
option, 'accept compound words' was checked yet apparently not available in
enchant. Because this non-acceptance was a chenge from the past lyx must
have changed the default spell checker in a recent upgrade and I hadn't
noticed. Probably because I didn't go looking for the reason.

  Thanks very much for the lesson.

Regards,

Rich



Re: LyX 2.3.1 -- Beamer presentation

2018-10-19 Thread Daniel

On 19/10/2018 13:17, F M Salter wrote:

Hi,

On Thu. 18 Oct 2018 04:26:19-0700, Baris Erkus wrote:


Please Submit a MWE.

BE

     MWE enclosed.

Regards
Frank Salter


Hi,

I couldn't compile the file at first and had to remove all equations for 
some reason. But I guess that is not the problem on your system.


As for the jump, there was a typewriter formatting between your first 
and second frame. I am not sure how it got there or why it causes this 
problem.


You can fix it by removing the separator between the first and second 
frame and adding it again. Or, alternatively, select the separator 
together with the second frame label "Frame (plain)" and reset the 
family via Text Style.


Is that what you were after?

Best,
Daniel



Re: LyX 2.3.1 -- Beamer presentation

2018-10-19 Thread F M Salter
Hi,

On Thu. 18 Oct 2018 04:26:19-0700, Baris Erkus wrote:
> 
> Please Submit a MWE.
>
> BE
    MWE enclosed.

Regards
Frank Salter


jump.lyx
Description: application/lyx


Re: An observation on 3.2.1 spell checking

2018-10-19 Thread Daniel

On 18/10/2018 22:26, Rich Shepard wrote:
   The document I'm now writing has many hyphenated words (e.g., 
Douglas-fir,
near-surface) and all are questioned by the spelling checker. I don't 
recall

seeing this before and don't know if its source is lyx or the spell checker
being used (I don't recall whether it's aspell or ispell).

   No action is required on anyone's part but I find it interesting that
these compound words are seen as being mis-spelled, even after I
(supposedly) add them to the dictionary.

Regards,

Rich


Those words are not marked on my system. I use Hunspell on Windows 
(which is installed as default with LyX, I think). You can check your 
spell-checker via


Preferences > Language Settings > Spellchecker

Best,
Daniel



Re: Exporting as PDF (cropped) is not cropping

2018-10-19 Thread Daniel

On 19/10/2018 11:54, list_em...@icloud.com wrote:

When I open a new document, type an equation, and export as PDF (cropped), I 
expect to see a PDF file that has zero extra white space around the graphical 
portion of the math. Instead, I see an entire page with the equation on the 
first line. I.e., no cropping. What am I doing wrong?

LyX 2.3.0

Jerry



Works for me on with LyX 2.3.1 on Windows 10. It crops from the equation 
to the page number, so the area is quite large but not the whole page. 
If I set the page layout page style to empty (via Document > Settings), 
I get the formula only.


(For a short time the full page is shown in the PDF viewer but it is 
almost immediately replaced by its cropped version.)


Daniel



Re: Parentheses keys are reversed in Hebrew

2018-10-19 Thread Jürgen Spitzmüller
Am Fr., 19. Okt. 2018 um 08:24 Uhr schrieb Guy Rutenberg <
guyrutenb...@gmail.com>:

> Hi,
>
> I've noticed a peculiar behavior when writing an Hebrew document in LyX.
> Whenever I type parentheses they get reversed. The problem does not happen
> when switching to English. For example if i type (  I get )
>  instead, and vice-versa. This happens with all kinds of
> bracketing including <>, [], {}.
>
>
> I can see the logic behind this, treating logically  as "opening
> parenthesis" and  as "closing parenthesis", and them mapping it,
> logically, to Hebrew which is right-to-left. However, this is quiet
> annoying, because no other program behaves that way.
>
> Is there a way to fix this?
>

Please comment here:
https://www.lyx.org/trac/ticket/11191

We generally need to audit LyX's behavior with bracket/parens input in RTL,
but we urgently need input from experienced users.

Jürgen



>
> Thanks,
> Guy
>


Exporting as PDF (cropped) is not cropping

2018-10-19 Thread list_email
When I open a new document, type an equation, and export as PDF (cropped), I 
expect to see a PDF file that has zero extra white space around the graphical 
portion of the math. Instead, I see an entire page with the equation on the 
first line. I.e., no cropping. What am I doing wrong?

LyX 2.3.0

Jerry

Re: Parentheses keys are reversed in Hebrew

2018-10-19 Thread Daniel

On 19/10/2018 08:23, Guy Rutenberg wrote:

Hi,

I've noticed a peculiar behavior when writing an Hebrew document in LyX. 
Whenever I type parentheses they get reversed. The problem does not 
happen when switching to English. For example if i type (  I 
get )  instead, and vice-versa. This happens with all kinds of 
bracketing including <>, [], {}.



I can see the logic behind this, treating logically  as 
"opening parenthesis" and  as "closing parenthesis", and them 
mapping it, logically, to Hebrew which is right-to-left. However, this 
is quiet annoying, because no other program behaves that way.


Is there a way to fix this?

Thanks,
Guy


I am not fully sure from what you write which parenthesis you get on 
which key combination.


In a document with Hebrew set as language I get "(" on  and ")" 
on . So, that seems to be what you desire. So, in that case I 
cannot reproduce what you see.


However, this is with an English, German, etc. keyboard layout. This 
changes if I switch to the Hebrew keyboard layout. But then the Hebrew 
keyboard layout seems to have parenthesis switched relative to the English:


https://en.wikipedia.org/wiki/Hebrew_keyboard#/media/File:Hebrew_keyboard_layout.png

So, if you are using a Hebrew keyboard layout, then LyX seems to behave 
correctly. But in that case I am wondering why other applications don't 
behave that way for you.


Best,
Daniel



Parentheses keys are reversed in Hebrew

2018-10-19 Thread Guy Rutenberg
Hi,

I've noticed a peculiar behavior when writing an Hebrew document in LyX.
Whenever I type parentheses they get reversed. The problem does not happen
when switching to English. For example if i type (  I get )
 instead, and vice-versa. This happens with all kinds of
bracketing including <>, [], {}.


I can see the logic behind this, treating logically  as "opening
parenthesis" and  as "closing parenthesis", and them mapping it,
logically, to Hebrew which is right-to-left. However, this is quiet
annoying, because no other program behaves that way.

Is there a way to fix this?

Thanks,
Guy