Re: Improvements for cross-referencing
On 4/10/20 2:55 PM, racoon wrote: > On 2020-04-10 20:29, Richard Kimberly Heck wrote: >> On 4/10/20 1:58 PM, Daniel wrote: >>> On 10/4/20 19:54, Richard Kimberly Heck wrote: On 4/10/20 5:05 AM, Daniel wrote: > On 2020-04-09 11:27, Daniel wrote: >> Attached is a simple concept of what it could look like. >> >> Daniel >> > > I think this fancy zig-zag is not important. The label could just > break at a space with a straight cut. This is how it currently works > in both Libre and Word. Seems good enough. Yes, we can't break labels over lines as things currently are. Riki >>> >>> I know. It was just an additional idea that would make the usage of >>> longer labels possible. But in general labels are not that long anyway, >>> so I don't think it should be a show stopper for the other suggestions. >> >> We have a similar problem even with textual insets. >> >> Riki > > I am not sure which a textual insets you have in mind. For example, > classic insets which can contain text are less often part of the > floating text. Footnotes, e.g., but really anything that lets you type into it. You might think we should be able to have: Here is some text. Here is some text. Here is[[FOOTNOTE: This is the text of the footnote, which goes across a few lines, and is broken in a sensible way.]] some text. Here is some text. But what you see is: Here is some text. Here is some text. Here is [[FOOTNOTE: This is the text of the footnote, which goes across a few lines, and is NOT broken in a sensible way. ]] some text. Here is some text. It's a dream of many of us to fix this, but it's super hard. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Improvements for cross-referencing
On 2020-04-10 20:29, Richard Kimberly Heck wrote: On 4/10/20 1:58 PM, Daniel wrote: On 10/4/20 19:54, Richard Kimberly Heck wrote: On 4/10/20 5:05 AM, Daniel wrote: On 2020-04-09 11:27, Daniel wrote: Attached is a simple concept of what it could look like. Daniel I think this fancy zig-zag is not important. The label could just break at a space with a straight cut. This is how it currently works in both Libre and Word. Seems good enough. Yes, we can't break labels over lines as things currently are. Riki I know. It was just an additional idea that would make the usage of longer labels possible. But in general labels are not that long anyway, so I don't think it should be a show stopper for the other suggestions. We have a similar problem even with textual insets. Riki I am not sure which a textual insets you have in mind. For example, classic insets which can contain text are less often part of the floating text. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Improvements for cross-referencing
On 4/10/20 1:58 PM, Daniel wrote: > On 10/4/20 19:54, Richard Kimberly Heck wrote: >> On 4/10/20 5:05 AM, Daniel wrote: >>> On 2020-04-09 11:27, Daniel wrote: Attached is a simple concept of what it could look like. Daniel >>> >>> I think this fancy zig-zag is not important. The label could just >>> break at a space with a straight cut. This is how it currently works >>> in both Libre and Word. Seems good enough. >> >> Yes, we can't break labels over lines as things currently are. >> >> Riki > > I know. It was just an additional idea that would make the usage of > longer labels possible. But in general labels are not that long anyway, > so I don't think it should be a show stopper for the other suggestions. We have a similar problem even with textual insets. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Jenkins build is back to normal : Build branch "master" » ubuntu-xenial-qt4-autotools-extended #1855
https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-xenial-qt4-autotools-extended/1855/ -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Improvements for cross-referencing
On 10/4/20 19:54, Richard Kimberly Heck wrote: On 4/10/20 5:05 AM, Daniel wrote: On 2020-04-09 11:27, Daniel wrote: Attached is a simple concept of what it could look like. Daniel I think this fancy zig-zag is not important. The label could just break at a space with a straight cut. This is how it currently works in both Libre and Word. Seems good enough. Yes, we can't break labels over lines as things currently are. Riki I know. It was just an additional idea that would make the usage of longer labels possible. But in general labels are not that long anyway, so I don't think it should be a show stopper for the other suggestions. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Improvements for cross-referencing
On 4/10/20 5:05 AM, Daniel wrote: > On 2020-04-09 11:27, Daniel wrote: >> Attached is a simple concept of what it could look like. >> >> Daniel >> > > I think this fancy zig-zag is not important. The label could just > break at a space with a straight cut. This is how it currently works > in both Libre and Word. Seems good enough. Yes, we can't break labels over lines as things currently are. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Offtopic: Qt licensing changes
What license would the development team need? el On 2020-01-28 17:33 , Pavel Sanda wrote: > Just FYI ( https://www.qt.io/blog/qt-offering-changes-2020 ): > > ... > Long-term-supported (LTS) releases will become available to commercial > licensees only > ... > Starting with Qt 5.15, long term support (LTS) will only be available to > commercial customers. This means open-source users will receive patch-level > releases of 5.15 until the next minor release will become available. .. We are > making this change to encourage open-source users to quickly adopt new > versions. This helps maximize the feedback we can get form the community and > to > emphasize the commercial support available to those with longer product life > cycles that rely on a specific Qt version. > -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Offtopic: Qt licensing changes
On Tue, Jan 28, 2020 at 04:33:31PM +0100, Pavel Sanda wrote: > Just FYI ( https://www.qt.io/blog/qt-offering-changes-2020 ): > > ... > Long-term-supported (LTS) releases will become available to commercial > licensees only > ... > Starting with Qt 5.15, long term support (LTS) will only be available to > commercial customers. This means open-source users will receive patch-level > releases of 5.15 until the next minor release will become available. .. We are > making this change to encourage open-source users to quickly adopt new > versions. This helps maximize the feedback we can get form the community and > to > emphasize the commercial support available to those with longer product life > cycles that rely on a specific Qt version. It seems that interesting times are ahead of us, since on top of that Qt announced that they are considering "restricting ALL Qt releases to paid license holders for the first 12 months." https://mail.kde.org/pipermail/kde-community/2020q2/006098.html Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Improvements for cross-referencing
On 2020-04-10 11:00, Daniel wrote:
On 2020-04-09 23:55, Richard Kimberly Heck wrote:
On 4/8/20 8:05 AM, Daniel wrote:
Ideally, these "labels" would be customizable so that the content
label string can be customized in the same way as label strings and
counters (as in "section \thesection" and "(\roman{enumiii})"). Again
some shared features. There would be commands for different cross
reference types, maybe "RefLabelString", "EqRefLabelString",
"FormatLabelString", and "NameRefLabelString". Again, these
customization could be utilized by LyXHTML as well.
We have the PrettyFormat tag, which is what controls the HTML output of
formatted references. What are you imagining that the others would do?
(FYI, all that was done before I added refstyle support. That's why the
caps and plurals aren't supported (yet).)
FormatRef: Yes, the PrettyFormat tag in counters is nice. Yes, capital
and plural support would be nice there. However, I think that for full
customization, the counter should be directly referable, in addition to
the LabelString via ##.
Use case: The Section layout is formatted as "1. Some heading". In this
case "section ##" will result in "section 1." but it should still be
"section 1".
By the way, theorem environments seem not to have PrettyFormats by
default. I could take a look and post a patch if that's helpful and not
yet in master.
Ref, EqRef: Currently, these references to enumerate lists will show the
counter label string in LyXHTML. But that is incorrect since it also
shows the period which is not shown in the latex output. Furthermore,
what will be shown in the latex output can be customized with the
enumitem package
(https://ftp.acc.umu.se/mirror/CTAN/macros/latex/contrib/enumitem/enumitem.pdf,
p. 5). Hence, the ability to customize the plain reference would be nice
as well. Again, it is not sufficient to refer to the LabelString via ##.
But I think that I was wrong to suggest a customization for both the
label of Ref and EqRef because only the label of Ref needs to be
customizable. EqRef just adds brackets.
NameRef: Currently, NameRef seems to show the same as FormatRef in
LyXHTML. However, in contrast, the latex output shows section headings.
Also, I think it would be nice if one could add labels to other elements
than headings such as description and labeling lists labels. This is not
officially supported by NameRef but kind of works in latex already by
default and can be made to work fully rather easily
(https://tex.stackexchange.com/a/526139).
In summary:
- PrettyFormat should be extended to be able use the counter directly as
is LabelString.
- Ref should be customizable similarly as well.
- NamRef should show what is shown in the latex output, i.e. heading or
list label.
Daniel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Build failed in Jenkins: Build branch "master" » ubuntu-xenial-qt4-autotools-extended #1854
https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-xenial-qt4-autotools-extended/1854/--
[...truncated 1582 lines...]
chmod a-w lyx-2.4.0dev
test -d lyx-2.4.0dev/_build || exit 0; \
dc_install_base=`CDPATH="${ZSH_VERSION+.}:" && cd lyx-2.4.0dev/_inst && pwd |
sed -e 's,^[^:\\/]:[\\/],/,'` \
&& dc_destdir="${TMPDIR-/tmp}/am-dc-$$/" \
&& am__cwd=`pwd` \
&& CDPATH="${ZSH_VERSION+.}:" && cd lyx-2.4.0dev/_build/sub \
&& ../../configure \
\
\
--srcdir=../.. --prefix="$dc_install_base" \
&& make \
&& make dvi \
&& make check \
&& make install \
&& make installcheck \
&& make uninstall \
&& make distuninstallcheck_dir="$dc_install_base" \
distuninstallcheck \
&& chmod -R a-w "$dc_install_base" \
&& ({ \
(cd ../.. && umask 077 && mkdir "$dc_destdir") \
&& make DESTDIR="$dc_destdir" install \
&& make DESTDIR="$dc_destdir" uninstall \
&& make DESTDIR="$dc_destdir" \
distuninstallcheck_dir="$dc_destdir" distuninstallcheck; \
} || { rm -rf "$dc_destdir"; exit 1; }) \
&& rm -rf "$dc_destdir" \
&& make dist \
&& rm -rf lyx-2.4.0dev.tar.gz lyx-2.4.0dev.tar.xz \
&& make distcleancheck \
&& cd "$am__cwd" \
|| exit 1
configuring LyX version 2.4.0dev
checking for build type... development
checking for version suffix...
checking whether Qt5 is disabled... no
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... x86_64-pc-linux-gnu
checking what packaging should be used... posix
checking whether to enable maintainer-specific portions of Makefiles... yes
checking whether make supports nested variables... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether UID '0' is supported by ustar format... yes
checking whether GID '0' is supported by ustar format... yes
checking how to create a ustar tar archive... gnutar
checking for a Python interpreter with version >= 2.7.0 or 3.5.0... python3
checking for python3... /usr/bin/python3
checking for python version... 3.5
checking for python platform... linux
checking for python script directory... ${prefix}/lib/python3.5/site-packages
checking for python extension module directory...
${exec_prefix}/lib/python3.5/site-packages
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for ar... ar
checking the archiver (ar) interface... ar
checking for ranlib... ranlib
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking whether the compiler is clang... no
checking for at least C++11 mode... -std=c++14
checking whether STL is libstdc++... yes
checking whether STL is libstdc++ using the C++11 ABI... yes
checking for correct regex implementation... yes
checking for std::call_once availability... yes
checking for gcc... gcc
checking whether we are using the GNU Objective C compiler... no
checking whether gcc accepts -g... no
checking dependency style of gcc... gcc3
checking dependency style of gcc... (cached) gcc3
checking for extra library directory... NONE
checking for extra include directory... NONE
checking for extra lib+include directory... NONE
checking for main in -lshlwapi... no
checking for main in -lpsapi... no
checking for main in -lgdi32... no
checking for main in -lole32... no
checking whether to use included boost library... yes
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether byte ordering is bigendian... no
checking whether printing callstack is possible... (cached) yes
checking whether make_unique is defined by header memory... yes
checking size of wchar_t... 4
checking for wchar_t... yes
checking for unsigned long long int... yes
checking for long long int... yes
checking for ld used by
Re: Improvements for cross-referencing
On 2020-04-09 11:27, Daniel wrote: Attached is a simple concept of what it could look like. Daniel I think this fancy zig-zag is not important. The label could just break at a space with a straight cut. This is how it currently works in both Libre and Word. Seems good enough. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Improvements for cross-referencing
On 2020-04-09 23:55, Richard Kimberly Heck wrote:
On 4/8/20 8:05 AM, Daniel wrote:
Ideally, these "labels" would be customizable so that the content
label string can be customized in the same way as label strings and
counters (as in "section \thesection" and "(\roman{enumiii})"). Again
some shared features. There would be commands for different cross
reference types, maybe "RefLabelString", "EqRefLabelString",
"FormatLabelString", and "NameRefLabelString". Again, these
customization could be utilized by LyXHTML as well.
We have the PrettyFormat tag, which is what controls the HTML output of
formatted references. What are you imagining that the others would do?
(FYI, all that was done before I added refstyle support. That's why the
caps and plurals aren't supported (yet).)
FormatRef: Yes, the PrettyFormat tag in counters is nice. Yes, capital
and plural support would be nice there. However, I think that for full
customization, the counter should be directly referable, in addition to
the LabelString via ##.
By the way, theorem environments seem not to have PrettyFormats by
default. I could take a look and post a patch if that's helpful and not
yet in master.
Ref, EqRef: Currently, these references to enumerate lists will show the
counter label string in LyXHTML. But that is incorrect since it also
shows the period which is not shown in the latex output. Furthermore,
what will be shown in the latex output can be customized with the
enumitem package
(https://ftp.acc.umu.se/mirror/CTAN/macros/latex/contrib/enumitem/enumitem.pdf,
p. 5). Hence, the ability to customize the plain reference would be nice
as well. Again, it is not sufficient to refer to the LabelString via ##.
But I think that I was wrong to suggest a customization for both the
label of Ref and EqRef because only the label of Ref needs to be
customizable. EqRef just adds brackets.
NameRef: Currently, NameRef seems to show the same as FormatRef in
LyXHTML. However, in contrast, the latex output shows section headings.
Also, I think it would be nice if one could add labels to other elements
than headings such as description and labeling lists labels. This is not
officially supported by NameRef but kind of works in latex already by
default and can be made to work fully rather easily
(https://tex.stackexchange.com/a/526139).
Daniel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
