Re: Update on the patches

[Guillaume Munch]

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 solution is the best and there is no more 
excuse not to do it, so yes, I will eventually. If you have any tip for 
installing it on Ubuntu without effort, please tell me.



Guillaume

Re: Update on the patches

[Jean-Marc Lasgouttes]

Le 20/10/2015 19:23, Guillaume Munch a écrit :

http://www.emacswiki.org/emacs/SmartTabs


Indeed, thanks. Do you use it?

JMarc

Re: Update on the patches

[Guillaume Munch]

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 a tab as 4 or 8
spaces wide or anything else, and this is IMHO a good thing (I have first
hand knowledge for preferenes of 2, 3, 4, and 8 spaces wide).


I would be interested by an emacs configuration that respects this. I
have to do it by hand every time...

JMarc




http://www.emacswiki.org/emacs/SmartTabs

Re: Update on the patches

[Jean-Marc Lasgouttes]

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 a tab as 4 or 8
spaces wide or anything else, and this is IMHO a good thing (I have first
hand knowledge for preferenes of 2, 3, 4, and 8 spaces wide).


I would be interested by an emacs configuration that respects this. I 
have to do it by hand every time...


JMarc

Re: Update on the patches

[Georg Baum]

Guillaume Munch wrote:

> Le 01/10/2015 00:43, Pavel Sanda a écrit :
>
>> This is interesting, I thought default tab is 8 and always
>> edited our sources this way. Kind of surprising that we didn't
>> conflicted yet about the visual appearance of indented blocks,
>> like in void ViewSourceWidget::restoreSession recently committed
>> by Guillaume.
>>
> 
> The various sources I found were very clear about 4. I saw such mismatch
> in trac, which is improperly configured to display 8.

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 a tab as 4 or 8 
spaces wide or anything else, and this is IMHO a good thing (I have first 
hand knowledge for preferenes of 2, 3, 4, and 8 spaces wide).


Georg

Re: Update on the patches

[Guillaume Munch]

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; the question is more: what is the
proper style to use?


Personally, I have the following, but have no idea of where it comes from.
I am open to something better (especially avoiding indenting in namespace).

;; Common hook
(defun my-c-mode-common-hook ()
   ;; Set return Style
;  (local-set-key [return] 'newline-and-indent)
;  (local-set-key [S-return] 'newline)
   (c-set-style "CC-MODE")
   (setq compile-command "make -k")
   )
(add-hook 'c-mode-common-hook 'my-c-mode-common-hook)

;; C++ mode hook
(defun my-c++-mode-hook ()
   ;; Style parameters
   (setq c-basic-offset 4
tab-width 4)



I have merged your example with mine and pushed it to 
developement/coding/emacs





This is interesting, I thought default tab is 8 and always
edited our sources this way. Kind of surprising that we didn't
conflicted yet about the visual appearance of indented blocks,
like in void ViewSourceWidget::restoreSession recently committed
by Guillaume.



The various sources I found were very clear about 4. I saw such mismatch 
in trac, which is improperly configured to display 8.


Guillaume

Re: Update on the patches

[Pavel Sanda]

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; the question is more: what is the
>> proper style to use?
>
> Personally, I have the following, but have no idea of where it comes from. 
> I am open to something better (especially avoiding indenting in namespace).
>
> ;; Common hook
> (defun my-c-mode-common-hook ()
>   ;; Set return Style
> ;  (local-set-key [return] 'newline-and-indent)
> ;  (local-set-key [S-return] 'newline)
>   (c-set-style "CC-MODE")
>   (setq compile-command "make -k")
>   )
> (add-hook 'c-mode-common-hook 'my-c-mode-common-hook)
>
> ;; C++ mode hook
> (defun my-c++-mode-hook ()
>   ;; Style parameters
>   (setq c-basic-offset 4
>   tab-width 4)

This is interesting, I thought default tab is 8 and always
edited our sources this way. Kind of surprising that we didn't
conflicted yet about the visual appearance of indented blocks,
like in void ViewSourceWidget::restoreSession recently committed
by Guillaume.

Pavel

Re: Update on the patches

[Richard Heck]

On 09/27/2015 11:47 PM, Guillaume Munch wrote:

Le 28/09/2015 04:31, Guillaume Munch a écrit :

Le 13/09/2015 22:28, Richard Heck a écrit :

On 09/12/2015 09:31 PM, Guillaume Munch wrote:


 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.


Don't know about this code.



No other feedback, so we'll see how it goes live. But I could test it in
real conditions so it should be fine. Pushed at 89342f29.




Also this is suitable for 2.1.x. My testing was done in stable already.


Give it a week or so and see if we get any complaints. If not, OK for 
stable.


Richard

Re: Update on the patches

[Jean-Marc Lasgouttes]

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; the question is more: what is the
proper style to use?


Personally, I have the following, but have no idea of where it comes 
from. I am open to something better (especially avoiding indenting in 
namespace).


;; Common hook
(defun my-c-mode-common-hook ()
  ;; Set return Style
;  (local-set-key [return] 'newline-and-indent)
;  (local-set-key [S-return] 'newline)
  (c-set-style "CC-MODE")
  (setq compile-command "make -k")
  )
(add-hook 'c-mode-common-hook 'my-c-mode-common-hook)

;; C++ mode hook
(defun my-c++-mode-hook ()
  ;; Style parameters
  (setq c-basic-offset 4
tab-width 4)
  (c-set-offset 'innamespace 0)
  )
(add-hook 'c++-mode-hook 'my-c++-mode-hook)


JMarc

Re: Update on the patches

[Guillaume Munch]

Le 13/09/2015 22:28, Richard Heck a écrit :

On 09/12/2015 09:31 PM, Guillaume Munch wrote:


 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.


Don't know about this code.



No other feedback, so we'll see how it goes live. But I could test it in 
real conditions so it should be fine. Pushed at 89342f29.

Re: Update on the patches

[Guillaume Munch]

Le 28/09/2015 04:31, Guillaume Munch a écrit :

Le 13/09/2015 22:28, Richard Heck a écrit :

On 09/12/2015 09:31 PM, Guillaume Munch wrote:


 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.


Don't know about this code.



No other feedback, so we'll see how it goes live. But I could test it in
real conditions so it should be fine. Pushed at 89342f29.




Also this is suitable for 2.1.x. My testing was done in stable already.

Re: Update on the patches

[Jean-Pierre Chrétien]

Le 15/09/2015 17:49, Guillaume Munch a écrit :

Le 14/09/2015 08:53, Jean-Marc Lasgouttes a écrit :



* 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?


In general the po files of master are reinitialized from the stable ones
shortly before release. If you want to modify fr.po it is a good idea to
coordinate with Jean-Pierre Chretien.




CC: Jean-Pierre

These are just accelerator fixes that I've just pushed. I hope that it does not
interfere and that I did it in the right way.


Thanks for doing it, just mention it in the changelog, I send you an edited copy 
by separate mail.


Just keep me posted if you have to do similar changes.

--
Jean-Pierre

Re: Update on the patches

[Guillaume Munch]

Le 14/09/2015 09:03, Jean-Marc Lasgouttes a écrit :

Le 14/09/2015 02:22, Guillaume Munch a écrit :

One thing that would have helped was to have emacs configuration
files with the correct coding style that you use.

For instance my .emacs now reads (omitting irrelevant parts):


Such information could go in the relevant code rule file in
development/.


(custom-set-variables ;; custom-set-variables was added by Custom.
;; If you edit it by hand, you could mess it up, so be careful. ;;
Your init file should contain only one such instance. ;; If there
is more than one, they won't work right. '(c-basic-indent 2)
'(column-number-mode t) '(indent-tabs-mode nil)
'(safe-local-variable-values (quote ((c-set-offset (quote
innamespace) 0) (c-set-style . "bsd" '(save-place t nil
(saveplace)) '(shell-command-switch "-lc" t) '(show-paren-mode t)
'(tab-width 2))


This part is your generic part that is overwritten for LyX right?

Why is BSD a good style?


I can add the files to the repository, but has anybody something
better to suggest?


The best is probaly to cut and paste a slimmed down version to the
relevant file in development/.




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; the question is more: what is the
proper style to use?




As already pointed out, RELEASE-NOTES is to keep track of changes
that affect LyX configuration files (the markup is markdown,
actually). New features are here: http://wiki.lyx.org/LyX/NewInLyX22


Thanks, done.

Re: Update on the patches

[Guillaume Munch]

Le 14/09/2015 08:53, Jean-Marc Lasgouttes a écrit :



* 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?


In general the po files of master are reinitialized from the stable ones
shortly before release. If you want to modify fr.po it is a good idea to
coordinate with Jean-Pierre Chretien.




CC: Jean-Pierre

These are just accelerator fixes that I've just pushed. I hope that it 
does not interfere and that I did it in the right way.



Guillaume

Re: Update on the patches

[Guillaume Munch]

Le 14/09/2015 23:39, Richard Heck a écrit :

On 09/13/2015 10:09 PM, Guillaume Munch wrote:

Le 13/09/2015 22:28, Richard Heck a écrit :

On 09/12/2015 09:31 PM, Guillaume Munch wrote:


* 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 don't use floats much so am a bad person to test. But if you actually
want discussion of the patch, yes, post it here.



Here's a rebased version because it had already diverged...

1. Support for (std|boost)::make_shared.
I did not sense enough smart-pointer energy radiating from the code...
Sorry for the recompilation times.

2. Do not show subfigures in the menu (bug #9759)
The improvements to the navigation menu described in the original
message above.

3. Better construction of the TOC  for floats and captions using a new
TocBuilder class
Fixes the situation caused by 2. in the outliner.

4. New class InsetCaptionable
Generalisation to wraps and listings and some code factoring.


These looks all right to me. I'd go ahead. If there are problems,
they'll show up soon enough.

Richard




Thanks. Committed in master, please report any issue.

Re: Update on the patches

[Richard Heck]

On 09/13/2015 10:09 PM, Guillaume Munch wrote:

Le 13/09/2015 22:28, Richard Heck a écrit :

On 09/12/2015 09:31 PM, Guillaume Munch wrote:


* 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 don't use floats much so am a bad person to test. But if you actually
want discussion of the patch, yes, post it here.



Here's a rebased version because it had already diverged...

1. Support for (std|boost)::make_shared.
I did not sense enough smart-pointer energy radiating from the code...
Sorry for the recompilation times.

2. Do not show subfigures in the menu (bug #9759)
The improvements to the navigation menu described in the original 
message above.


3. Better construction of the TOC  for floats and captions using a new 
TocBuilder class

Fixes the situation caused by 2. in the outliner.

4. New class InsetCaptionable
Generalisation to wraps and listings and some code factoring.


These looks all right to me. I'd go ahead. If there are problems, 
they'll show up soon enough.


Richard

Re: Update on the patches

[Scott Kostyshak]

On Tue, Sep 15, 2015 at 02:50:46AM +0100, Guillaume Munch wrote:
> Le 14/09/2015 05:04, Scott Kostyshak a écrit :
> >On Mon, Sep 14, 2015 at 03:42:15AM +0100, Guillaume Munch wrote:
> >>Le 14/09/2015 03:17, Scott Kostyshak a écrit :
> >>>put a link to the lyx-devel message on the trac ticket.
> >>
> >>How do you find this link?
> >
> >Well, I just do [a and mutt copies it to my clipboard (I have a
> >script). I am guessing you could do the same with Thunderbird but I am
> >not familiar with it. You have a few options. You can just go here:
> >http://news.gmane.org/gmane.editors.lyx.devel
> >and wait a few minutes for the message to show up. Or you can ask
> >Thunderbird for the message ID of a certain email, and then use that.
> >For example, the email you just sent can be found with the message ID as
> >follows:
> >http://mid.gmane.org/mt5c67$o2k$1...@ger.gmane.org
> >If you put that link into the browser, you get the following URL:
> >http://article.gmane.org/gmane.editors.lyx.devel/156697
> >I actually prefer the mid.gmane link because it has the message ID in
> >the URL. That way, if mail-archive disappears or reindexes the messages
> >such that the direct URLs change, you can always just use the message ID
> >to find it on a different mail archiver (they have similar ways to
> >search by message ID) or we can search our mail box locally by message
> >ID. Even GMail web interface has a way to search by message ID. This
> >way, the thread can always be found.
> >
> >Scott
> >
> 
> Thanks. I just noticed that there's a contextual menu entry to copy the
> message url. For yours I get the following:
> news://news.gmane.org:119/20150914040426.ga13...@optiplex-9020.ad.ufl.edu
> Is this a format that works for most people?

It is fine for me because it has the message ID but others probably
prefer an http link. You can turn the message ID into a link by the
following:
http://mid.gmane.org/20150914040426.ga13...@optiplex-9020.ad.ufl.edu

I should emphasize that the above thoughts are just my personal
preference. Many people do not care about keeping things so organized
and cross-referenced. I think they have better memories than I do.

Scott

Re: Update on the patches

[Guillaume Munch]

Le 14/09/2015 05:04, Scott Kostyshak a écrit :

On Mon, Sep 14, 2015 at 03:42:15AM +0100, Guillaume Munch wrote:

Le 14/09/2015 03:17, Scott Kostyshak a écrit :

put a link to the lyx-devel message on the trac ticket.


How do you find this link?


Well, I just do [a and mutt copies it to my clipboard (I have a
script). I am guessing you could do the same with Thunderbird but I am
not familiar with it. You have a few options. You can just go here:
http://news.gmane.org/gmane.editors.lyx.devel
and wait a few minutes for the message to show up. Or you can ask
Thunderbird for the message ID of a certain email, and then use that.
For example, the email you just sent can be found with the message ID as
follows:
http://mid.gmane.org/mt5c67$o2k$1...@ger.gmane.org
If you put that link into the browser, you get the following URL:
http://article.gmane.org/gmane.editors.lyx.devel/156697
I actually prefer the mid.gmane link because it has the message ID in
the URL. That way, if mail-archive disappears or reindexes the messages
such that the direct URLs change, you can always just use the message ID
to find it on a different mail archiver (they have similar ways to
search by message ID) or we can search our mail box locally by message
ID. Even GMail web interface has a way to search by message ID. This
way, the thread can always be found.

Scott



Thanks. I just noticed that there's a contextual menu entry to copy the 
message url. For yours I get the following:

news://news.gmane.org:119/20150914040426.ga13...@optiplex-9020.ad.ufl.edu
Is this a format that works for most people?

Guillaume

Re: Update on the patches

[Jean-Marc Lasgouttes]

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

* 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.


In such cases, set the milestone to the relevant stable version and add 
Richard in copy. THis allows him to follow the bugs that are candidate 
for branch.



* 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.


As already pointed out, RELEASE-NOTES is to keep track of changes that 
affect LyX configuration files (the markup is markdown, actually). New 
features are here:

http://wiki.lyx.org/LyX/NewInLyX22

This file will be used to write the NEWS file before release. This is 
much less detailed than the status.* files and only covers the new features.



* 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?


In general the po files of master are reinitialized from the stable ones 
shortly before release. If you want to modify fr.po it is a good idea to 
coordinate with Jean-Pierre Chretien.


JMarc

Re: Update on the patches

[Jean-Marc Lasgouttes]

Le 14/09/2015 02:44, Guillaume Munch a écrit :

I read:

   !Important Changes in LyX 2.2.0

   (: This file lists interface changes that might affect users in
   2.2.0, some known problems in LyX 2.2.0 and some things you have to
   take into account when upgrading from earlier versions to a version
   of the 2.2.x series. :)

It looks for mostly to be for important changes that might affect users,
known problems, caveats when upgrading... Where do I advertise new
feature like improvements to the source panel? Where is the file that
make people happy about downloading the new version?


Advertising is in NEWS and and the wiki (we could try to make this 
available in About LyX too). This one is more a technical reference for 
people who have customized LyX by hand. It is useful to us too.




(Also I imagine that the markup ! vs !! vs !!! means section/subsection
etc. but it's not really clear.)


Take a look at the about LyX dialog to see what the result is.

JMarc

Re: Update on the patches

[Jean-Marc Lasgouttes]

Le 14/09/2015 02:22, Guillaume Munch a écrit :

One thing that would have helped was to have emacs configuration files
with the correct coding style that you use.

For instance my .emacs now reads (omitting irrelevant parts):


Such information could go in the relevant code rule file in development/.


(custom-set-variables
  ;; custom-set-variables was added by Custom.
  ;; If you edit it by hand, you could mess it up, so be careful.
  ;; Your init file should contain only one such instance.
  ;; If there is more than one, they won't work right.
  '(c-basic-indent 2)
  '(column-number-mode t)
  '(indent-tabs-mode nil)
  '(safe-local-variable-values
(quote
 ((c-set-offset
   (quote innamespace)
   0)
  (c-set-style . "bsd"
  '(save-place t nil (saveplace))
  '(shell-command-switch "-lc" t)
  '(show-paren-mode t)
  '(tab-width 2))


This part is your generic part that is overwritten for LyX right?

Why is BSD a good style?


I can add the files to the repository, but has anybody something better
to suggest?


The best is probaly to cut and paste a slimmed down version to the 
relevant file in development/.


JMarc

Re: Update on the patches

[Georg Baum]

Guillaume Munch wrote:

> * 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?

Note that you do not need to change po files if you don't want to (even if 
you change translatable strings). There are some developers who take care of 
this. If you want to be nice and change the po files, then I am actually 
unsure how the recommended procedure is.

> * 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?

If you want to get feedback please do so. Then you get more attention, if 
you just put them on trac then one has to actively search for new bugs one 
might want to comment on.

> * 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).

Sorry, this was shortly before I went on vacation, and afterwards I forgot.

I re-read the patch, and do not have objections (previosuly I was unsure 
about consistency of interpreting any text as LaTeX when creating a math 
inset, but this is already done for creating a complete formula).


Georg

Re: Update on the patches

[Richard Heck]

On 09/12/2015 10:19 PM, Scott Kostyshak wrote:

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

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.


Seconded.




* 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.


And yes, they are fine. But...




* 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.


...do make sure to do this for stable.

I think one does NOT need to update RELEASE-NOTES for fixes that also go 
to stable, since they are documented in status.21x. Only changes that 
are master-only need to go there, and these are usually feature 
additions, behavior changes, and the like.


Richard

Re: Update on the patches

[Richard Heck]

On 09/12/2015 09:31 PM, Guillaume Munch wrote:

* 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 don't use floats much so am a bad person to test. But if you actually 
want discussion of the patch, yes, post it here.


* 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).


Looks good.

 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.


Don't know about this code.

 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.


JMarc will know.

rh

Re: Update on the patches

[Scott Kostyshak]

On Mon, Sep 14, 2015 at 12:39:38AM +0100, Guillaume Munch wrote:
> Le 13/09/2015 12:55, Georg Baum a écrit :
> >Guillaume Munch wrote:
> >
> >>* 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?
> >
> >Note that you do not need to change po files if you don't want to
> >(even if you change translatable strings). There are some developers
> >who take care of this. If you want to be nice and change the po
> >files, then I am actually unsure how the recommended procedure is.
> 
> 
> I will need the correct procedure; otherwise I am just going to assume
> in the future that I can commit po files to stable and master at once.

Whatever is decided should be documented in lib/doc/Development.lyx. If
you have the interest, Guillaume, anything you wish to add to
Development.lyx that you've found confusing about joining Lyx's
development would be great. I think there are a lot of unwritten
practices we have that make it complicated for newcommers. One of the
goals of having that file is that newcommers can have a central place to
look for our practices.

Scott

Re: Update on the patches

[Guillaume Munch]

Le 14/09/2015 03:17, Scott Kostyshak a écrit :

put a link to the lyx-devel message on the trac ticket.


How do you find this link?

Re: Update on the patches

[Guillaume Munch]

Le 13/09/2015 21:52, Richard Heck a écrit :

On 09/12/2015 10:19 PM, Scott Kostyshak wrote:

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

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.


Seconded.


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.


And yes, they are fine. But...




* 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.


...do make sure to do this for stable.




Done.



I think one does NOT need to update RELEASE-NOTES for fixes that also
go to stable, since they are documented in status.21x. Only changes
that are master-only need to go there, and these are usually feature
 additions, behavior changes, and the like.



I read:

  !Important Changes in LyX 2.2.0

  (: This file lists interface changes that might affect users in
  2.2.0, some known problems in LyX 2.2.0 and some things you have to
  take into account when upgrading from earlier versions to a version
  of the 2.2.x series. :)

It looks for mostly to be for important changes that might affect users, 
known problems, caveats when upgrading... Where do I advertise new 
feature like improvements to the source panel? Where is the file that 
make people happy about downloading the new version?


(Also I imagine that the markup ! vs !! vs !!! means section/subsection 
etc. but it's not really clear.)



Guillaume

Re: Update on the patches

[Guillaume Munch]

Le 13/09/2015 12:55, Georg Baum a écrit :

Guillaume Munch wrote:


* 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?


Note that you do not need to change po files if you don't want to
(even if you change translatable strings). There are some developers
who take care of this. If you want to be nice and change the po
files, then I am actually unsure how the recommended procedure is.



I will need the correct procedure; otherwise I am just going to assume
in the future that I can commit po files to stable and master at once.






* 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).


Sorry, this was shortly before I went on vacation, and afterwards I
forgot.

I re-read the patch, and do not have objections (previosuly I was
unsure about consistency of interpreting any text as LaTeX when
creating a math inset, but this is already done for creating a
complete formula).





Thanks, done in master at 61145265.

Guillaume

Re: Update on the patches

[Scott Kostyshak]

On Sun, Sep 13, 2015 at 01:55:59PM +0200, Georg Baum wrote:
> Guillaume Munch wrote:
> 
> > * 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?
> 
> If you want to get feedback please do so. Then you get more attention, if 
> you just put them on trac then one has to actively search for new bugs one 
> might want to comment on.

I agree that bringing the patches to the list is the best way to get
feedback. However, I also like having them on trac. Otherwise patches
can get lost. What I personally prefer is to post the patch on the trac
ticket, then if I don't get a response there and I want feedback, I send
a message to the list and immediately (so I don't forget) put a link to
the lyx-devel message on the trac ticket.

Scott

Re: Update on the patches

[Guillaume Munch]

Le 14/09/2015 01:00, Scott Kostyshak a écrit :

On Mon, Sep 14, 2015 at 12:39:38AM +0100, Guillaume Munch wrote:

Le 13/09/2015 12:55, Georg Baum a écrit :

Guillaume Munch wrote:


* 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?


Note that you do not need to change po files if you don't want to
(even if you change translatable strings). There are some developers
who take care of this. If you want to be nice and change the po
files, then I am actually unsure how the recommended procedure is.



I will need the correct procedure; otherwise I am just going to assume
in the future that I can commit po files to stable and master at once.


Whatever is decided should be documented in lib/doc/Development.lyx. If
you have the interest, Guillaume, anything you wish to add to
Development.lyx that you've found confusing about joining Lyx's
development would be great. I think there are a lot of unwritten
practices we have that make it complicated for newcommers. One of the
goals of having that file is that newcommers can have a central place to
look for our practices.

Scott



I have found a great deal of information already on the website and the 
repository.


One thing that would have helped was to have emacs configuration files 
with the correct coding style that you use.


For instance my .emacs now reads (omitting irrelevant parts):


(custom-set-variables
 ;; custom-set-variables was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 '(c-basic-indent 2)
 '(column-number-mode t)
 '(indent-tabs-mode nil)
 '(safe-local-variable-values
   (quote
((c-set-offset
  (quote innamespace)
  0)
 (c-set-style . "bsd"
 '(save-place t nil (saveplace))
 '(shell-command-switch "-lc" t)
 '(show-paren-mode t)
 '(tab-width 2))

;; c++ style for lyx-devel
(defun my-c-setup ()
   (c-set-offset 'innamespace [0]))
(add-hook 'c++-mode-hook 'my-c-setup)



and the .dir-locals.el reads:


 ((nil . ((indent-tabs-mode . t)
 (tab-width . 4)
 (fill-column . 80)))
 (c-mode . ((c-file-style . "BSD")
(c-basic-offset . 4)
(c-set-style . "bsd")))
 (c++-mode . ((c-basic-offset . 4)
  (c-set-style . "bsd")))
 )


I can add the files to the repository, but has anybody something better 
to suggest?



Guillaume

Re: Update on the patches

[Guillaume Munch]

Le 14/09/2015 01:22, Guillaume Munch a écrit :

and the .dir-locals.el reads:


  ((nil . ((indent-tabs-mode . t)
  (tab-width . 4)
  (fill-column . 80)))
  (c-mode . ((c-file-style . "BSD")
 (c-basic-offset . 4)
 (c-set-style . "bsd")))
  (c++-mode . ((c-basic-offset . 4)
   (c-set-style . "bsd")))
  )


I can add the files to the repository, but has anybody something better
to suggest?


Guillaume




To make it clear, I would add the .dir-locals.el it to lib/doc, not to 
the root...

Re: Update on the patches

[Guillaume Munch]

Le 13/09/2015 22:28, Richard Heck a écrit :

On 09/12/2015 09:31 PM, Guillaume Munch wrote:


* 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 don't use floats much so am a bad person to test. But if you actually
want discussion of the patch, yes, post it here.



Here's a rebased version because it had already diverged...

1. Support for (std|boost)::make_shared.
I did not sense enough smart-pointer energy radiating from the code...
Sorry for the recompilation times.

2. Do not show subfigures in the menu (bug #9759)
The improvements to the navigation menu described in the original 
message above.


3. Better construction of the TOC  for floats and captions using a new 
TocBuilder class

Fixes the situation caused by 2. in the outliner.

4. New class InsetCaptionable
Generalisation to wraps and listings and some code factoring.


>From 0b39537d33cf3a336de05833a839fb688c06e27a Mon Sep 17 00:00:00 2001
From: Guillaume Munch 
Date: Wed, 2 Sep 2015 19:53:13 +0100
Subject: [PATCH 4/4] New class InsetCaptionable

This generalises the new use of TocBuilder (97e8101) to listings and wraps and
removes some duplicate code.

Make sure that we will never write an empty float type again in the future
(#9760)
---
 src/Makefile.am  |  2 +
 src/frontends/qt4/TocModel.cpp   | 12 +++--
 src/frontends/qt4/TocModel.h |  6 ++-
 src/insets/InsetCaptionable.cpp  | 94 ++
 src/insets/InsetCaptionable.h| 54 ++
 src/insets/InsetCollapsable.cpp  | 13 --
 src/insets/InsetCollapsable.h|  2 -
 src/insets/InsetFloat.cpp| 98 ++--
 src/insets/InsetFloat.h  | 14 +++---
 src/insets/InsetListings.cpp | 28 +++-
 src/insets/InsetListings.h   |  6 +--
 src/insets/InsetListingsParams.h |  2 +-
 src/insets/InsetWrap.cpp | 47 ---
 src/insets/InsetWrap.h   |  8 ++--
 14 files changed, 234 insertions(+), 152 deletions(-)
 create mode 100644 src/insets/InsetCaptionable.cpp
 create mode 100644 src/insets/InsetCaptionable.h

diff --git a/src/Makefile.am b/src/Makefile.am
index cf25556..35d890f 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -573,6 +573,7 @@ SOURCEFILESINSETS = \
 	insets/InsetBox.cpp \
 	insets/InsetBranch.cpp \
 	insets/InsetCaption.cpp \
+	insets/InsetCaptionable.cpp \
 	insets/InsetCitation.cpp \
 	insets/InsetCollapsable.cpp \
 	insets/InsetCommand.cpp \
@@ -631,6 +632,7 @@ HEADERFILESINSETS = \
 	insets/InsetBox.h \
 	insets/InsetBranch.h \
 	insets/InsetCaption.h \
+	insets/InsetCaptionable.h \
 	insets/InsetCitation.h \
 	insets/InsetCode.h \
 	insets/InsetCollapsable.h \
diff --git a/src/frontends/qt4/TocModel.cpp b/src/frontends/qt4/TocModel.cpp
index a0059f7..c2cda38 100644
--- a/src/frontends/qt4/TocModel.cpp
+++ b/src/frontends/qt4/TocModel.cpp
@@ -80,8 +80,9 @@ public:
 
 TocModel::TocModel(QObject * parent)
 	: model_(new TocTypeModel(parent)),
-	sorted_model_(new QSortFilterProxyModel(parent)),
-	is_sorted_(false), toc_(0), maxdepth_(0), mindepth_(0)
+	  sorted_model_(new QSortFilterProxyModel(parent)),
+	  is_sorted_(false), toc_(make_shared()),
+	  maxdepth_(0), mindepth_(0)
 {
 	sorted_model_->setSortLocaleAware(true);
 	sorted_model_->setSourceModel(model_);
@@ -108,6 +109,7 @@ void TocModel::clear()
 {
 	model_->blockSignals(true);
 	model_->clear();
+	toc_ = make_shared();
 	model_->blockSignals(false);
 }
 
@@ -157,9 +159,9 @@ void TocModel::updateItem(DocIterator const & dit)
 }
 
 
-void TocModel::reset(Toc const & toc)
+void TocModel::reset(shared_ptr toc)
 {
-	toc_ = 
+	toc_ = toc;
 	if (toc_->empty()) {
 		maxdepth_ = 0;
 		mindepth_ = 0;
@@ -364,7 +366,7 @@ void TocModels::reset(BufferView const * bv)
 		iterator mod_it = models_.find(type);
 		if (mod_it == models_.end())
 			mod_it = models_.insert(type, new TocModel(this));
-		mod_it.value()->reset(*it->second);
+		mod_it.value()->reset(it->second);
 
 		// Fill in the names_ model.
 		QString const gui_name = guiName(it->first, bv->buffer().params());
diff --git a/src/frontends/qt4/TocModel.h b/src/frontends/qt4/TocModel.h
index 83e957b..6b4315b 100644
--- a/src/frontends/qt4/TocModel.h
+++ b/src/frontends/qt4/TocModel.h
@@ -12,6 +12,8 @@
 #ifndef TOCMODEL_H
 #define TOCMODEL_H
 
+#include "support/shared_ptr.h"
+
 #include 
 #include 
 
@@ -36,7 +38,7 @@ public:
 	///
 	TocModel(QObject * parent);
 	///
-	void reset(Toc const & toc);
+	void reset(shared_ptr);
 	///
 	void reset();
 	

Re: Update on the patches

[Scott Kostyshak]

On Mon, Sep 14, 2015 at 03:42:15AM +0100, Guillaume Munch wrote:
> Le 14/09/2015 03:17, Scott Kostyshak a écrit :
> >put a link to the lyx-devel message on the trac ticket.
> 
> How do you find this link?

Well, I just do [a and mutt copies it to my clipboard (I have a
script). I am guessing you could do the same with Thunderbird but I am
not familiar with it. You have a few options. You can just go here:
http://news.gmane.org/gmane.editors.lyx.devel
and wait a few minutes for the message to show up. Or you can ask
Thunderbird for the message ID of a certain email, and then use that.
For example, the email you just sent can be found with the message ID as
follows:
http://mid.gmane.org/mt5c67$o2k$1...@ger.gmane.org
If you put that link into the browser, you get the following URL:
http://article.gmane.org/gmane.editors.lyx.devel/156697
I actually prefer the mid.gmane link because it has the message ID in
the URL. That way, if mail-archive disappears or reindexes the messages
such that the direct URLs change, you can always just use the message ID
to find it on a different mail archiver (they have similar ways to
search by message ID) or we can search our mail box locally by message
ID. Even GMail web interface has a way to search by message ID. This
way, the thread can always be found.

Scott

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

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