Re: Update on the patches

[Guillaume Munch]

Le 13/09/2015 03:19, Scott Kostyshak a écrit :

On Sun, Sep 13, 2015 at 02:31:27AM +0100, Guillaume Munch wrote:

Dear list,



I've pushed the patches that we discussed.


First of all, congrats on your push! I am now enjoying the
improvements you just committed and I am looking forward to your
future work on LyX. You already seem to have an excellent
understanding of some of LyX's components.


Thank you :)




* f3008c30 and 4d1ad336 are suitable for stable. Shall I commit
them?


The person who will decide is the branch maintainer, who is Richard.
If it is not code that he feels qualified to judge, he either asks
someone else to confirm the code is safe or asks you if you are
confident.


I know. I was asking Richard :) BTW I am assuming that we are releasing
soon 2.2 so I try not to push for new features in stable.



* Am I responsible for updating the release notes? If so, do all
the little bug fixes have to be mentioned?


I am still unsure how to go about this. From what I understand,
whenever committing to branch, you should always update status.21x.
As for master, when I know that one of my commits will *not* be
backported to branch, I look at RELEASE-NOTES and see if the change
belongs to one of the categories. Unfortunately I think there are a
lot of changes that should be documented in RELEASE-NOTES that are
not. I know I am sometimes guilty of forgetting to do it.


Yes this does not sound like a sure process for master. I'll bear that
in mind for stable.





* Where should I commit po files? I vaguely remember reading
somewhere that these should be against stable, do I remember
correctly and in that case is it better to commit to master at the
same time?

* I would like to discuss another set of patches that makes it
convenient to navigate within floats: see
. To test the patch please
compare the behaviour, before and after, of the navigation menus
and of the outliner, in the presence of floats with 1) subfloats,
2) multiple captions, 3) a total number of floats and subfloats of
the same type > 30. Detailed changes are in the patch header, as
usual. Would you prefer that I post directly the patches on the
list in the future?

* I am going to commit a few others smaller patches if there is no
objection:

 Math commands used in text
mode should use the current selection as contents : already tested
by Scott but in an earlier message Georg also commented and I did
not get whether he had any objection (I did not get a follow-up to
my reply).

 MathData::updateMacros()
breaks text selection and search/replace : I believe that these two
calls to clearSelection() are not (or no longer) useful. I am very
happy to see this bug gone.

 Insets should not be inline
if they contain a displayed inset : an inset occupies the full
available width if it contains displayed insets, but for the
exception of lone displayed insets which are shown inline (example:
a displayed math in a note). The solution is to check explicitly
whether the first sub-inset is a display. Small discussion in the
bug report.


I don't know the response to your other questions.

Scott




Thanks.

Guillaume

Re: Update on the patches

[Scott Kostyshak]

On Sun, Sep 13, 2015 at 02:31:27AM +0100, Guillaume Munch wrote:
> Dear list,

> I've pushed the patches that we discussed.

First of all, congrats on your push! I am now enjoying the improvements
you just committed and I am looking forward to your future work on LyX.
You already seem to have an excellent understanding of some of LyX's
components.

> * f3008c30 and 4d1ad336 are suitable for stable. Shall I commit them?

The person who will decide is the branch maintainer, who is Richard. If
it is not code that he feels qualified to judge, he either asks someone
else to confirm the code is safe or asks you if you are confident.

> * Am I responsible for updating the release notes? If so, do all the
> little
> bug fixes have to be mentioned?

I am still unsure how to go about this. From what I understand, whenever
committing to branch, you should always update status.21x. As for
master, when I know that one of my commits will *not* be backported to
branch, I look at RELEASE-NOTES and see if the change belongs to one of
the categories. Unfortunately I think there are a lot of changes that
should be documented in RELEASE-NOTES that are not. I know I am
sometimes guilty of forgetting to do it.

> * Where should I commit po files? I vaguely remember reading somewhere
> that
> these should be against stable, do I remember correctly and in that
> case is
> it better to commit to master at the same time?
>
> * I would like to discuss another set of patches that makes it
> convenient to
> navigate within floats: see . To
> test
> the patch please compare the behaviour, before and after, of the
> navigation
> menus and of the outliner, in the presence of floats with 1)
> subfloats, 2)
> multiple captions, 3) a total number of floats and subfloats of the
> same
> type > 30. Detailed changes are in the patch header, as usual. Would
> you
> prefer that I post directly the patches on the list in the future?
> 
> * I am going to commit a few others smaller patches if there is no
> objection:
> 
>  Math commands used in text mode
> should
> use the current selection as contents : already tested by Scott but in
> an
> earlier message Georg also commented and I did not get whether he had
> any
> objection (I did not get a follow-up to my reply).
> 
>  MathData::updateMacros() breaks
> text
> selection and search/replace : I believe that these two calls to
> clearSelection() are not (or no longer) useful. I am very happy to see
> this
> bug gone.
> 
>  Insets should not be inline if
> they
> contain a displayed inset : an inset occupies the full available width
> if it
> contains displayed insets, but for the exception of lone displayed
> insets
> which are shown inline (example: a displayed math in a note). The
> solution
> is to check explicitly whether the first sub-inset is a display. Small
> discussion in the bug report.

I don't know the response to your other questions.

Scott

Re: LyX on high resolution displays

[Scott Kostyshak]

On Sat, Sep 12, 2015 at 11:48:37PM +, David wrote:
> OS: Windows 10
> LyX version: 2.1.4
> 
> I recently purchased a 4K resolution monitor (3840 by 2160). 
> 
> By using LyX's zoom settings I can make text and formulas look a nice size.
> However, the icons on the toolbar in LyX now appear very small as do the
> pallets at the bottom of the window.
> 
> Is it on the roadmap either for LyX to become fully HiDPI aware? If so, is
> there an estimated time frame for this to happen?
> 
> Thanks,
> David

I believe we have improvements that will be released with LyX 2.2.0.
There is no date we have for its release, but it is a few months away
from what I understand.

I know you are using Windows, but if by chance you dual boot with
Ubuntu, let me know and I can give you installation files you can test.

Best,

Scott

Update on the patches

[Guillaume Munch]

Dear list,


I've pushed the patches that we discussed.

* f3008c30 and 4d1ad336 are suitable for stable. Shall I commit them?

* Am I responsible for updating the release notes? If so, do all the 
little bug fixes have to be mentioned?


* Where should I commit po files? I vaguely remember reading somewhere 
that these should be against stable, do I remember correctly and in that 
case is it better to commit to master at the same time?


* I would like to discuss another set of patches that makes it 
convenient to navigate within floats: see 
. To test the patch please compare 
the behaviour, before and after, of the navigation menus and of the 
outliner, in the presence of floats with 1) subfloats, 2) multiple 
captions, 3) a total number of floats and subfloats of the same type > 
30. Detailed changes are in the patch header, as usual. Would you prefer 
that I post directly the patches on the list in the future?


* I am going to commit a few others smaller patches if there is no 
objection:


 Math commands used in text mode 
should use the current selection as contents : already tested by Scott 
but in an earlier message Georg also commented and I did not get whether 
he had any objection (I did not get a follow-up to my reply).


 MathData::updateMacros() breaks 
text selection and search/replace : I believe that these two calls to 
clearSelection() are not (or no longer) useful. I am very happy to see 
this bug gone.


 Insets should not be inline if 
they contain a displayed inset : an inset occupies the full available 
width if it contains displayed insets, but for the exception of lone 
displayed insets which are shown inline (example: a displayed math in a 
note). The solution is to check explicitly whether the first sub-inset 
is a display. Small discussion in the bug report.




Guillaume

Re: Crash on Fedora 23 on copying or cutting text

[José Matos]

On Friday 11 September 2015 23:33:52 Georg Baum wrote:
> The attached patch fixes the crash. Shall I apply it?
> 
> 
> Georg

Please do. :-)
I can confirm that it solves all the crashes I had before (FWIW I am just 
testing 2.1.4).

Best regards,
-- 
José Abílio

Re: mailing list test

[Jerry]

On Sep 6, 2015, at 12:23 PM, Stephan Witt  wrote:

> Am 06.09.2015 um 20:09 schrieb Richard Heck :
> 
>> On 09/05/2015 04:11 AM, Stephan Witt wrote:
>>> Sorry for this test, but I don't get any mails for lyx-devel and lyx-users 
>>> anymore since the 8th of August or so.
>>> 
>>> I tried to subscribe again and to mail to help for lyx-devel without any 
>>> response.
>>> 
>>> So, I'll see if this message show up in the mail archive.
>> 
>> Weird. This message did get through.
> 
> I'm not on the list of the subscribers anymore. Posts are allowed for 
> everyone.
> I don't know what's wrong with my mail address.
> 
> Stephan

I've had similar problems with both dev and users' lists and just now started 
receiving messages again. I received an automated message from the dev list a 
couple days ago, replied as advised, got a message that I was already 
subscribed, and now am getting messages from both list once again.

Jerry

LyX on high resolution displays

[David]

OS: Windows 10
LyX version: 2.1.4

I recently purchased a 4K resolution monitor (3840 by 2160). 

By using LyX's zoom settings I can make text and formulas look a nice size.
However, the icons on the toolbar in LyX now appear very small as do the
pallets at the bottom of the window.

Is it on the roadmap either for LyX to become fully HiDPI aware? If so, is
there an estimated time frame for this to happen?

Thanks,
David

Re: Linker error while building Lyx 2.2 on OSX

[david]

Thanks Stephan.




When I launch this version of LyX, I got an error saying that textclasses could 
not be found, which persisted even after I had updated the paths to match my 
LyX 2.1 settings exactly. Are there any paths hardcoded into the build?




~David

On Sun, Sep 6, 2015 at 7:03 AM, Stephan Witt  wrote:

>> I’m having some difficulty building Lyx 2.2 (commit 0bbc80f) on OSX. 
>> Currently 
>> using Xcode 6.4 on OSX 10.10.5 and Qt 5.5.0 installed via Homebrew. 
>> automake.sh 
>> runs fine, and so does configure invoked as follows:
>> 
>> 
>> ./configure --with-version-suffix=-2.2 --with-libiconv-prefix=/usr 
>> --with-x=no 
>> --disable-stdlib-debug --prefix=/Users/ddinh/Applications/Lyx-2.2.app 
>> --with-qt-dir=/usr/local/opt/qt5 --enable-qt5 --enable-cxx11
>> 
>> 
>> which gives:
>> 
>> 
>> Configuration
>>   Host type:   x86_64-apple-darwin14.5.0
>>   Special build flags:  build=development warnings assertions c++11-mode 
>> stdregex use-aspell use-enchant
>>   C++ Compiler:g++
>>   C++ Compiler flags:   -Wall -Wextra -fPIC -g -O -std=c++11 
>> -Wno-deprecated-register
>>   C++ Compiler user flags:
>>   Linker flags:
>>   Linker user flags:
>>   Qt Frontend:
>>   Qt version:  5.5.0
>>   Packaging:   macosx
>>   LyX binary dir:  
>> /Users/ddinh/Applications/Lyx-2.2.app/Contents/MacOS
>>   LyX files dir:   
>> /Users/ddinh/Applications/Lyx-2.2.app/Contents/Resources
>> 
>> 
>> On a call to make, compilation seems to work but linking fails as follows:
>> 
>> 
>> rm -f hash-temp \
>> @echo "  GEN  lyx_commit_hash.h";hash=`cd ".." && git log -1 
>> --pretty=format:%H 2>/dev/null || echo none` ; \
>> sed s/@LYX_GIT_COMMIT_HASH@/$hash/ "."/lyx_commit_hash.h.in 
>> >hash-temp 
>> ; \
>> cmp -s lyx_commit_hash.h hash-temp || cp hash-temp lyx_commit_hash.h 
>> ; \
>> rm -f hash-temp
>>   CXXLDlyx
>> clang: error: unknown argument: '-framework QtConcurrent'
>> clang: error: unknown argument: '-framework QtSvg'
>> clang: error: unknown argument: '-framework QtWidgets'
>> clang: error: unknown argument: '-framework QtMacExtras'
>> clang: error: unknown argument: '-framework QtGui'
>> clang: error: unknown argument: '-framework QtCore'
>> make[4]: *** [lyx] Error 1
>> make[3]: *** [all-recursive] Error 1
>> make[2]: *** [all] Error 2
>> make[1]: *** [all-recursive] Error 1
>> make: *** [all] Error 2
>> 
>> 
>> Does anyone have experience with this error, or binaries of lyx 2.2?
> Hi David,
> I didn't use Homebrew before but I know of difficulties to build LyX with Qt 
> from MacPorts.
> I'm able to compile and link LyX with Qt frameworks I've built myself on my 
> Mac from source.
> I've made a disk image with LyX-2.2.0 at git commit 
> 211ac35314d661127c407635af880bcf1679ddba.
> You can grab it and a detached gpg-signature from dropbox here:
> https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0dev-211ac35%2Bqt5-x86_64-cocoa.dmg
> https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0dev-211ac35%2Bqt5-x86_64-cocoa.dmg.sig
> Regards,
> Stephan

Re: textcommands in math mode

[Enrico Forestieri]

On Thu, Sep 10, 2015 at 02:14:26PM +, Guenter Milde wrote:

> Dear LyX developers,
> 
> LyX mis-handles some text commands in math mode.
> 
> Try:
> 
> * open LyX,
> * open a new document,
> * open a math box (CTRL-M)
> * write  \text\AA
> 
> This looks completely OK (a letter A-with-ring (Å) appears) but fails to
> compile.
> 
> The source panel shows the reason - LyX believes this is a math command and
> hence wraps it in \ensuremath:
> 
>$\text{\ensuremath{\AA}}$
>
> This wrapping is correct for \alpha or \neq, but not \AA.
> 
> Other affected commands are \O (Ø 00D8LATIN CAPITAL LETTER O WITH 
> STROKE)
> and \textdegree (° 00B0   DEGREE SIGN)
> 
> A complete discussion and patch are at  http://www.lyx.org/trac/ticket/9742
> 
> Please review and apply.

I think that all is needed is the attached patch.

-- 
Enrico
diff --git a/lib/symbols b/lib/symbols
index 89fc41a..0bdaa98 100644
--- a/lib/symbols
+++ b/lib/symbols
@@ -1167,15 +1167,15 @@ else
 \def\Join{|x|}  amssymb
 endif
 # Fixme: latin-1 chars in text file
-\def\AA{\AA}{Å}
-\def\O{\O}{Ø}
+\def\AA{\AA}{Å} textmode Å
+\def\O{\O}{Ø}   textmode Ø
 
 iffont cmsy
 # The \sim is placed too high...
 \def\cong{\stackrel{_\sim}{=}}
 lyxsurd   cmsy112 0 mathord  √
 \def\surd{^\lyxsurd}
-\def\textdegree{\kern-1mu^{\circ}\kern-4mu}
+\def\textdegree{\kern-1mu^{\circ}\kern-4mu} textmode °
 else
 # FIXME: These don't work on OS X, since the Symbol font uses a different
 #encoding and is therefore disabled in FontLoader::available().
diff --git a/src/mathed/MacroTable.h b/src/mathed/MacroTable.h
index 030e6f7..bc445d4 100644
--- a/src/mathed/MacroTable.h
+++ b/src/mathed/MacroTable.h
@@ -68,6 +68,8 @@ public:
 	///
 	char const * MathMLtype() const;
 	///
+	latexkeys const * symbol() const { return sym_; }
+	///
 	void setSymbol(latexkeys const * sym) { sym_ = sym; }
 	///
 	DocIterator const & pos() { return pos_; }
diff --git a/src/mathed/MathMacro.cpp b/src/mathed/MathMacro.cpp
index 7901128..aead6b8 100644
--- a/src/mathed/MathMacro.cpp
+++ b/src/mathed/MathMacro.cpp
@@ -889,7 +889,9 @@ bool MathMacro::folded() const
 
 void MathMacro::write(WriteStream & os) const
 {
-	MathEnsurer ensurer(os, d->macro_ != 0, true);
+	bool const needs_mathmode =
+		d->macro_ != 0 && d->macro_->symbol()->extra != "textmode";
+	MathEnsurer ensurer(os, needs_mathmode, true);
 
 	// non-normal mode
 	if (d->displayMode_ != DISPLAY_NORMAL) {

Problem with InsetMathSideset::dyb

[Jean-Marc Lasgouttes]

Coverity points out that in the code below, des is overwritten without 
being used. The same happens in dyt(). Georg, any comment?


JMarc

int InsetMathSideset::dyb(BufferView const & bv) const
128{
129int nd = ndes(bv);
130int des = 0;
131if (scriptl_ && scriptr_)
132des = max(bl().dimension(bv).ascent(), 
br().dimension(bv).ascent());

133else if (scriptl_)
134des = bl().dimension(bv).ascent();
135else if (scriptr_)
136des = br().dimension(bv).ascent();
137int na = nasc(bv);
138des = dybt(bv, na, nd, false);
139return des;
140}

Re: [LyX/master] Add missing braces

[Jean-Marc Lasgouttes]

Le 12/09/15 18:48, Jean-Marc Lasgouttes a écrit :

Le 12/09/15 18:43, Jean-Marc a écrit :

commit 61f02710317b99a050346a0c95c02fcdd457bfca
Author: Jean-Marc 
Date:   Sat Sep 12 18:40:52 2015 +0200

 Add missing braces

 Coverity issue 23506.


This is an example of a bug found by coverity amidst lots of nit
picking. However doing the boring part is important since it allows to
make the important part visible.


Another example from lyxfinc.cpp. Can you spot what is wrong with the 
loop? I cannot fix that myself unfortunately. Tommaso?


JMarc

 915   for (; re_it != re_it_end; ++re_it) {
 916   match_results const & m = *re_it;
 917   // Check braces on the segment that matched the entire 
regexp expression,
 918   // plus the last subexpression, if a (.*?) was inserted 
in the constructor.

 919   if (!braces_match(m[0].first, m[0].second, open_braces))
 920   return 0;
 921   // Check braces on segments that matched all (.*?) 
subexpressions,

 922   // except the last "padding" one inserted by lyx.
 923   for (size_t i = 1; i < m.size() - 1; ++i)
 924   if (!braces_match(m[i].first, m[i].second))
 925   return false;
 926   // Exclude from the returned match length any length
 927   // due to close wildcards added at end of regexp
 928   if (close_wildcards == 0)
 929   return m[0].second - m[0].first;
 930   else
 931   return m[m.size() - close_wildcards].first - 
m[0].first;

 932   }

Re: [LyX/master] Add missing braces

[Jean-Marc Lasgouttes]

Le 12/09/15 18:43, Jean-Marc a écrit :

commit 61f02710317b99a050346a0c95c02fcdd457bfca
Author: Jean-Marc 
Date:   Sat Sep 12 18:40:52 2015 +0200

 Add missing braces

 Coverity issue 23506.


This is an example of a bug found by coverity amidst lots of nit 
picking. However doing the boring part is important since it allows to 
make the important part visible.


I encourage developers with free time (ha !) to register on coverity and 
ask for access to

https://scan.coverity.com/projects/4164

BTW Liviu, could you update the source tree at coverity?

JMarc


@@ -2869,10 +2869,11 @@ QTreeWidgetItem * 
PrefShortcuts::insertShortcutItem(FuncRequest const & lfun,
QList const items = 
shortcutsTW->findItems(lfun_name,
Qt::MatchFlags(Qt::MatchExactly | Qt::MatchRecursive), 
0);
for (int i = 0; i < items.size(); ++i) {
-   if (items[i]->text(1) == shortcut)
+   if (items[i]->text(1) == shortcut) {
newItem = items[i];
break;
}
+   }
// if not found, this unbind item is KeyMap::UserExtraUnbind
// Such an item is not displayed to avoid confusion (what is
// unmatched removed?).

Re: Crash on Fedora 23 on copying or cutting text

[Jean-Marc Lasgouttes]

Le 12/09/15 13:58, Georg Baum a écrit :

Jean-Marc Lasgouttes wrote:


I suspect a compiler bug.


After further thinking about it I agree and reported it:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67557


The attached patch fixes the crash. Shall I apply it?


Sure, it makes the code cleaner anyway. Did you try to run valgrind with
it to make sure that everything is OK?


Yes, and it did not complain.


Please go ahead then.

JMarc

Re: Crash on Fedora 23 on copying or cutting text

[Georg Baum]

Jean-Marc Lasgouttes wrote:

> I suspect a compiler bug.

After further thinking about it I agree and reported it: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67557

>> The attached patch fixes the crash. Shall I apply it?
> 
> Sure, it makes the code cleaner anyway. Did you try to run valgrind with
> it to make sure that everything is OK?

Yes, and it did not complain.


Georg

Re: Crash on Fedora 23 on copying or cutting text

[Jean-Marc Lasgouttes]

Le 11/09/15 23:33, Georg Baum a écrit :

fontToStartTag() is a function that constructs a StartTag and returns it.
Then, the copy constructor StartTag::StartTag() is called, constructing the
FontTag object from the temporary StartTag object, and finally font_type_ is
initialized. Calling a copy constructor from a constructor of a derived
class is a bit awkward, but I do not understand why it leads to a crash
(maybe because I did not dig into the details with return value optimization
etc). Does anybody know more?


I suspect a compiler bug.


The attached patch fixes the crash. Shall I apply it?


Sure, it makes the code cleaner anyway. Did you try to run valgrind with 
it to make sure that everything is OK?


JMarc