Re: ESC Key
On 2023-01-22 13:44, Daniel wrote:
On 2023-01-22 10:25, Evan Langlois wrote:
Is there some way to reconfigure LyX to not have ESC cancel a dialog
or at least ask me first? I tried to remove the keybinding for esc in
the preferences, but that didn't help. The issue is that I use vi, so
when editing the preamble my hand just hits the esc key to save out of
habit. All my changes are then gone without a "Hey you changed stuff!
Are you sure?"
I don't think there is a way. And I am not sure it is a common enough
case to allow for a preference or so.
But it sounds like you would be satisfied with LyX asking whether to
discard changes made to the preamble before cancelling the dialog. I
think that is generally a good idea. After all, it is like editing your
document where we also don't just let the user close the window without
asking.
Daniel
Attached is a simple patch that avoids the dialog being closed when the
Esc key is pressed. The patch presupposes the source code patch to
ticket #12577 (https://www.lyx.org/trac/ticket/12577).
As suggested above, at least additionally, there should also be a
warning when source codes where changed whether the dialog should be
closed. But that is not implemented with this patch.
Daniel
From 80748b0a03441ca6f959d9776eef8a092aef644c Mon Sep 17 00:00:00 2001
From: Daniel Ramoeller
Date: Sun, 22 Jan 2023 16:31:53 +0100
Subject: [PATCH 2/2] When editing source code, prevent Escape key
When editing source code, e.g. the local layout or the LaTeX preamble, pressing
the Esc key leads to the dialog being closed. This is prevented by the patch.
---
src/frontends/qt/GuiSourceEdit.cpp | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/frontends/qt/GuiSourceEdit.cpp
b/src/frontends/qt/GuiSourceEdit.cpp
index 9b008a5d03..e451688752 100644
--- a/src/frontends/qt/GuiSourceEdit.cpp
+++ b/src/frontends/qt/GuiSourceEdit.cpp
@@ -300,7 +300,9 @@ void GuiSourceEdit::keyPressEvent(QKeyEvent *event)
modifyMarkerInSel("\t", REMOVE);
else if (event->key() == Qt::Key_Return)
newLineWithInheritedIndentation();
- else
+ else if (event->key() == Qt::Key_Escape) {
+// Ignore the ESC key so that the dialog isn't closed
+ } else
// Call base class for other events
QTextEdit::keyPressEvent(event);
}
--
2.24.3 (Apple Git-128)
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: List Preamble Arguments
On 2020-10-26 15:55, Richard Kimberly Heck wrote: On 10/26/20 10:22 AM, Daniel wrote: On 2020-10-26 15:09, Daniel wrote: On 2020-10-26 12:30, Daniel wrote: On 2020-10-13 23:52, Richard Kimberly Heck wrote: On 10/13/20 5:15 PM, Richard Kimberly Heck wrote: Hi, all (but especially Jürgen), There have been two cases recently where people have asked about using the new counter insets to set the value of e.g., the enumi counter. The problem here is the old 'list preamble' one that is solved by the new 'list preamble' arguments. However, because those have PassThru set, you can't actually insert the counter inset, and I think that's usually true with PassThru, right? Should we disable PassThru here (people can use ERT if that's what they want)? Or are there special cases where insets should be allowed with PassThru? Never mind. That doesn't work properly anyway. We need some other way to deal with enumi etc. I have a patch for (re)setting/resuming counters, including numbered lists: https://www.lyx.org/trac/ticket/12010. I like it because it's very similar to what one has in other word processors. The final obstacle is that I don't see no easy way to add an argument to the list preamble (in this case "resume*"). There is the list preamble inset (https://www.lyx.org/trac/changeset/b124adbd3837/lyxgit). However, if I see it correctly, there is no interface currently to add arguments to the list preamble directly (via code not via inset). Does anyone know whether that is correct? If so, does anyone have an idea on how to implement what is need? Maybe I can have a look at some other feature and learn from that? Any comments much appreciated! Maybe ParagraphParameters.cpp's labelwidthstring could work? Sorry, please disregard my previous comments. I got too excited. :) I should stick to the tracker. I'll have a look later today or tomorrow. Riki Thanks, but no hurry at all! Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Manage counters
On 2020-10-13 17:49, Richard Kimberly Heck wrote:
On 10/13/20 1:43 AM, Daniel wrote:
On 2020-10-13 00:24, Richard Kimberly Heck wrote:
On 10/12/20 4:58 AM, Daniel wrote:
I think it's nice to have the inset available but its use is limited
for me. In particular, it seems not a feature to "directly" change the
counter of numbered elements. Here is what I mean: Say, I want to
change the counter of a Numbered list (enumerate). In the attached
document I try to reset a Numbered list counter with the inset but it
doesn't work. This is because `\setcounter` comes either too early
(outside of the enumerate environment) or too late (after `\item`). I
think to work, `\setcounter` should be added '''at the beginning or
the line''' where the counter inset is added as in the attached tex
document.
Scott pointed out the same issue. To make it work, you have to Insert>
List Preamble (an optional argument), and then you also have to modify
the layout for that argument to remove PassThru. (This is on the list a
couple weeks back.) Otherwise, you can't insert insets but only bare
text. It's not ideal but it's also not clear what else to do. Generally
removing PassThru seems wrong, since that's what one will ordinarily
want, I think.
Somehow I could not get it to work by removing PassThru. But I suspect
that the following two problems will remain:
1. The counter *in the Workarea* is not properly modified since the
counter inset still comes after the list started.
That's likely true, but can probably be fixed somehow. I'll have to
investigate.
2. Changing the first element in a list works different from changing
other elements in a list. Which is quite counter-intuitive.
I agree. It's not ideal how it works with lists. I didn't really have
lists in mind when designing this. (Scott's own use case is better
handled with enumitem's resume function, e.g.)
The idea of using the context menu, etc, is a good one, but it would
involve more work.
I guess you mean "more work" as in more work than for the counter inset.
My hopes are not high that I will be able to do it. I'll still try it at
some point little bit. I hope I can learn a lot from the counter inset
code.
I think this would have to be done by making the counter value a
paragraph parameter, like line spacing. That's where we store this kind
of thing. The option would be available in the dialog only when the
paragraph has an associated counter.
Thanks a lot for the hints. And please always let me know if you would
be yourself interested in implementing it. I am not particularly fond of
implementing any particular feature myself. I know any of the developers
would do a better job. I am only taking some on because the developers
seem busy with other things.
I am also thinking of being able to set not only the value but the
format, e.g. "(\roman{enumi})", of the counter, ideally via a nice UI
with a couple of preset values.
Here, I think it might be worth just having a module that made other
formats available. I have one for local use.
It strikes me as a pretty basic feature that should be available
module-less some day.
Possibly. But the difficulty is that this kind of case can be made for
many features. If all of them are available by default, then the result
is chaos. Modules were specifically designed to allow people to turn
things on and off as they need them or don't.
I agree that making all features default might be chaotic and like the
concept of modules. However, this is a default feature of the common
word processors, so one might be able to make a special case for it that
way. However, someone else would have to make that case.
Daniel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Layout list WYSIWYM
On 2020-08-16 21:16, Jean-Marc Lasgouttes wrote: Le 16 août 2020 16:08:25 GMT+02:00, racoon a écrit : On 2020-08-16 16:06, Richard Kimberly Heck wrote: Pavel was joking. Was he? I see. I am still not sure about JMarc though. Anyway, I'll add a gui switch as Jürgen asked for. In general, I am against a new switch, but I would have to see the actual result. Our preference dialog is really a mess IMO. I can think about a good place. In general, ever thought about a further switch called "Advanced Preferences"? Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Layout list WYSIWYM
On 2020-08-16 16:06, Richard Kimberly Heck wrote: On 8/16/20 3:24 AM, Daniel wrote: On 2020-08-03 15:49, Pavel Sanda wrote: On Sun, Aug 02, 2020 at 12:04:46PM +0200, Jean-Marc Lasgouttes wrote: Le 2 ao??t 2020 10:18:50 GMT+02:00, "Jürgen Spitzmüller" a écrit : Am Sonntag, den 02.08.2020, 09:44 +0200 schrieb Daniel: Do you prefer a ui or non-ui switch? A pref entry would be fine (JMarc, I hear you screaming!). Just pretend you did not hear me :) Design of single combo box looks like exactly situation where we should have fight over single solution than providing another gui switch. I saw that there are gui switches for sorting and grouping environments. Does this only apply to the layout combo box so far (maybe that should be made explicit in the gui)? If so, I am inclined to think that if these warrant a gui switch, so does the formatted text layout box. Pavel was joking. I see. I am still not sure about JMarc though. Anyway, I'll add a gui switch as Jürgen asked for. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Patches
On 2020-08-10 09:19, Richard Kimberly Heck wrote: On 8/10/20 12:23 AM, Daniel wrote: On 2020-08-09 19:41, Richard Kimberly Heck wrote: On 8/9/20 1:04 PM, Richard Kimberly Heck wrote: On 8/9/20 5:45 AM, Daniel wrote: I have produced a number of (unsolicited) patches. I will stop doing so for now until some of them are either rejected or commited to master. Otherwise, I fear that I will have to redo them (partly), like this one https://www.lyx.org/trac/ticket/10328, or inconsistencies with further patches. That is pretty normal. If you use git branches, then you won't have that much work to do. I am already doing that. But if a patch does not apply to master, then I am stuck with re-making it. I guess I need to learn how to partly apply a patch and such. Also, it does not help when improving a new feature if the feature might not be accepted. You don't have to remake the whole thing, just fix the places where you get conflicts. I.e., something like: git checkout -b mybranch ...do lots of work... ...wait a while until things have changed... git rebase master # now we get conflicts and we fix them. I'll try that. PS Some of these are not your patches. You might want to unassign yourself. I don't think I have assigned any of those to me. Should I? If you have posted a patch, then you probably should assign yourself. Then you can more easily keep track of which patches are yours and which aren't. (I.e., you search for bugs for which you are assigned, not just the ones that you own.) Let me know if you have issues with that. I can fix whatever permissions need to be fixed. If I assign myself to a ticket, then the person being assigned by default is removed, right? So, that would mean that I am the only one who gets updates when I change something. How should I then make people aware that I have a patch that might be in their area of expertise? Cc the person who was assigned by default? Post it on the list? Both? FYI, you can also create a custom page for yourself by e.g. going to https://www.lyx.org/trac/wiki/HomeRacoon and then editing that page. See e.g. my version at https://www.lyx.org/trac/wiki/HomeRikiHeck which was stolen years ago from Vincent. Stole yours now. I'll try modify it later. Many of these are display things, which are not my forte. I've looked at the rest. Thanks for checking! My pleasure. Please know that your patches are very welcome. It is a weird time, though, and I at least am struggling day to day just to keep up with daily stuff. Had an uncle die of Covid in April and one of my partner's best friends a few weeks ago, too But we have two new kittens (!), and they are an unending source of amusement. https://photos.app.goo.gl/i7EMuKwVoggpoHru9 Thanks. I didn't mean to complain or so. Just thought that work could be more effective if I worked while more people where around to check and discuss it. But good to know they are (mostly) welcome. I guess if a patch sits around for a couple of years I should bring it up again on the list. :) I am sorry to hear about your losses... Is that a very small cat or a very big screen? :) -- Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Groupbox layout
On 2020-08-06 07:28, Stephan Witt wrote: Am 06.08.2020 um 05:01 schrieb Daniel : On 2020-08-06 00:02, Stephan Witt wrote: Am 05.08.2020 um 12:47 schrieb Stephan Witt : Am 04.08.2020 um 05:36 schrieb Daniel : On 2020-08-04 00:03, Daniel wrote: On 2020-08-03 22:43, Stephan Witt wrote: Am 03.08.2020 um 16:52 schrieb Daniel : On 3/8/20 16:20, Jürgen Spitzmüller wrote: Am Montag, den 03.08.2020, 16:09 +0200 schrieb Daniel: Thanks. I hope you did not compile the list manually. :) No: grep setFlat *.h I was actually hoping that there could be a general way to affect all boxes with "one" call. But if my search for this does not bear fruit, I'll resort to the manual solution. I doubt you can do this generally. Seemed to me like something one should be able to do. But probably I will need to ask on stackexchange… Something like the attached patch? It’s only a hack for the preferences to get the idea. This can be put in a helper method and called when it seems appropriate. Stephan Nice! It seems to work as expected. And I think it improves the readability of the preferences on mac. My hunch is that we would want the analogue for every other OS but with "setFlat(true)" because currently not all group boxes are set to flat and likely some will be missed in the future. Just to be sure: the method relies on the particular creation process of panels by the Preferences dialog, right? It can probably be adapted for the Document Settings dialog but would not (easily) work on the lowesy (application) level. Yes, the method enumerates the child widgets after initial UI setup. This method works for the Preferences dialog as the code is placed there. Other methods I can imagine would be: 1. put the code at a lower level of the class hierarchy for dialogs and make it more general that way or 2. create a own GUI class derived from QGroupbox, override the init code and use that instead of the Qt class (don’t know how to do this in designer) Next patch with more general scope - I’ve moved the code to dialog factory utility GuiView::findOrBuild(). Great, seems to work everywhere as expected (dialogs and widgets). So, I guess what is missing is the part with: #else flatGroupBoxes(dialog->asQWidget(), true); May be. I did not hear the applause for your proposal :) So, I’d rather left it as an open task for an improvement for other devs. Stephan I am a bit worried this will get lost then. I seem to remember that when I first saw that group boxes where sometimes flat and suggested to give them their default layout, that Jürgen said that they should be invariably flat. But seeing the effect on macOS, he probably thought it's okay with the default there. So, I am inclined to think that he would applaud these changes. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: #10571: Tabs not showing properly in macOS full (and split) screen
On 2020-08-05 12:39, Stephan Witt wrote: Am 02.08.2020 um 19:17 schrieb Daniel : On 2020-08-02 18:10, Stephan Witt wrote: Am 02.08.2020 um 13:25 schrieb Daniel : On 2020-08-02 10:55, Stephan Witt wrote: Am 01.08.2020 um 16:51 schrieb Stephan Witt : Am 01.08.2020 um 09:35 schrieb Daniel : On 2020-08-01 09:32, Stephan Witt wrote: Am 31.07.2020 um 07:13 schrieb Daniel : On 2020-07-30 21:21, Stephan Witt wrote: Am 29.07.2020 um 22:59 schrieb Daniel : On 2020-07-29 21:03, Stephan Witt wrote: Am 29.07.2020 um 10:15 schrieb LyX Ticket Tracker : #10571: Tabs not showing properly in macOS full (and split) screen ---+- Reporter: racoon | Owner: lasgouttes Type: defect | Status: new Priority: normal | Milestone: Component: general| Version: 2.2.2 Severity: normal | Resolution: Keywords: os=macosx | ---+- Comment (by racoon): … Okay, tested again. It happens under a special condition: when the LyX window is previously maximized (not in fullscreen but maximized by double clicking the title bar). So: 1. Double click the title bar (maximizes the window) This one is configurable. Alternatively the double click sends it to the dock (minimize it). 2. Click on View > Fullscreen (enters fullscreen) 3. Click on View > Fullscreen (exits fullscreen) I don’t understand what’s not working. It looks like maximizing the window is not full-screen. What I see here (Catalina) is that after existing the fullscreen via LyX's dedicated function (Step 3), the fullscreen is immediately re-activated. The only way to get out of it is using the WM's fullscreen button. I see. This isn’t the case with my latests (not published) patch anymore (hopefully). Here is the current state of my patch to improve switch to/from full-screen. It contains additional code to detect switch to/from window maximize state. This is actually not used yet. On Mac it could be a possibility to implement the switch to/from the state you’ve called „focus mode“. That’s why I left it as is ATM. The final patch will be without it and the maximize state can be done later. For now I’d like to ask Pavel how this is different and/or managed on Linux. Perhaps it doesn’t work the same way as on Mac. Does it work as expected for you and on Linux? Can anyone test it on Windows, please? Very nice! You haven't asked explicitly for macOS feedback but I guess that is welcome as well. Yes, thank you. Seems to work almost perfectly on macOS now. There is one small exception: when doing the last three steps mentioned above, the window gets out of the maximized state. But it's really small. And maybe it's just a Qt bug. There is a difference between maximized and full-screen state. To be sure I understand your recipe: 1. Maximize window (alt green dot) 2. Switch to full-screen (Command-Control-f) 3. Switch back from full-screen (Command-Control-f) With these steps I can reproduce that LyX doesn’t return to maximized state. This is correct - „code wise“, but the WM remembers the previous maximized state. So the behavior is different when using the green dot to switch to and from full-screen. With the latter LyX returns to maximized state. The effect of the really small window I cannot reproduce. But it’s reported already as ticket 11909 here: https://www.lyx.org/trac/ticket/11909 (IMO). Oh, I am sorry. The reference of the "really small" was to "small exception". I don't get a really small window. (Just the pre-maximization state.) I’ve checked this effect with Qt 5.9 on Mac. This works for me. So I’d say it’s a Qt problem and we have to live with it. Stephan Thanks for checking. As I said, it seem like a very small problem anyway. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Ticket #9376: Limit text width in the editor window (non-fullscreen mode)
On 2020-08-01 13:42, Stephan Witt wrote:
Am 01.08.2020 um 12:50 schrieb racoon :
On 2020-08-01 12:43, Stephan Witt wrote:
Am 01.08.2020 um 09:48 schrieb Daniel :
I am trying to fix Ticket #9376. My attempt so far is attached. However, I have
hit a little road block in that the clang compiler does not give me useful
information (for me at least):
CXXLDlyx
Undefined symbols for architecture x86_64:
"std::__1::basic_string, std::__1::allocator >
lyx::convert, std::__1::allocator >,
lyx::Length>(lyx::Length)", referenced from:
lyx::LyXRC::write(std::__1::basic_ostream >&, bool,
std::__1::basic_string, std::__1::allocator > const&)
const in liblyxcore.a(LyXRC.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
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
ERROR: Cannot build and install lyx for x86_64.
Maybe someone knows what I might be doing wrong?
IMO, it’s the change from int for full_screen_width to Length for screen_width.
In LyXRC::write() the operator << is not implemented for Length, probably.
Sounds plausible. So, short of implementing << for length, I should
probably store the length in some other format, like string. Length
seems to have a function for that: asString().
Yes, the lyxrc file stores strings only anyway :)
You have a similar problem with the opposite direction.
The "lexrc >> screen_width“ construct may not lead to errors at compile or link
time.
But may result in dataloss silently if the >> operator doesn’t do the right
thing.
Furthermore the move from „\fullscreen_width“ to „\screen_width“ in rc file
requires
the appropriate converter for existing rc files to the new syntax.
Yes, a pref2pref conversion is necessary anyway, since the new version
should store a length and a unit while the previous one only stored a
length.
Okay, I give up for now.
I tried to do it properly with strings this time. However, I can't
figure out how to get a Length from a string. From the name
Length::Length(string const & data)
seemed promising but I don't think it's the right function. (By the way
"widgetsToLength" also does not what the name suggests, i.e. it returns
a string rather than a Length.)
I am still getting the linker failure with the patch attached.
Daniel
diff --git a/src/BufferView.cpp b/src/BufferView.cpp
index fe02be5019..3758387e99 100644
--- a/src/BufferView.cpp
+++ b/src/BufferView.cpp
@@ -345,12 +345,13 @@ int BufferView::rightMargin() const
{
// The value used to be hardcoded to 10
int const default_margin = zoomedPixels(10);
+ int const screen_width = inPixels(Length(lyxrc.screen_width));
// The additional test for the case the outliner is opened.
- if (!full_screen_ || !lyxrc.full_screen_limit
- || width_ < lyxrc.full_screen_width + 2 * default_margin)
+ if (!lyxrc.screen_limit
+ || width_ < screen_width + 2 * default_margin)
return default_margin;
- return (width_ - lyxrc.full_screen_width) / 2;
+ return (width_ - screen_width) / 2;
}
@@ -2129,7 +2130,7 @@ void BufferView::dispatch(FuncRequest const & cmd,
DispatchResult & dr)
icp["key"] = from_utf8(arg);
if (!opt1.empty())
icp["before"] = from_utf8(opt1);
- icp["literal"] =
+ icp["literal"] =
from_ascii(InsetCitation::last_literal ? "true" :
"false");
string icstr = InsetCommand::params2string(icp);
FuncRequest fr(LFUN_INSET_INSERT, icstr);
diff --git a/src/LyXRC.cpp b/src/LyXRC.cpp
index 42df207154..57d5078b80 100644
--- a/src/LyXRC.cpp
+++ b/src/LyXRC.cpp
@@ -112,13 +112,13 @@ LexerKeyword lyxrcTags[] = {
{ "\\format", LyXRC::RC_FILEFORMAT },
{ "\\forward_search_dvi", LyXRC::RC_FORWARD_SEARCH_DVI },
{ "\\forward_search_pdf", LyXRC::RC_FORWARD_SEARCH_PDF },
- { "\\fullscreen_limit", LyXRC::RC_FULL_SCREEN_LIMIT },
+ { "\\screen_limit", LyXRC::RC_SCREEN_LIMIT },
{ "\\fullscreen_menubar", LyXRC::RC_FULL_SCREEN_MENUBAR },
{ "\\fullscreen_scrollbar", LyXRC::RC_FULL_SCREEN_SCROLLBAR },
{ "\\fullscreen_statusbar", LyXRC::RC_FULL_SCREEN_STATUSBAR },
{ "\\fullscreen_tabbar", LyXRC::RC_FULL_SCREEN_TABBAR },
{ "\\fullscreen_toolbars", LyXRC::RC_FULL_SCREEN_TOOLBARS },
- { "\\fullscreen_width", LyXRC::RC_FULL_SCREEN_WIDTH },
+ { "\\screen_width", LyXRC::RC_SCREEN_WIDTH },
{ "\\group_layo
Re: Ticket #9376: Limit text width in the editor window (non-fullscreen mode)
On 2020-08-01 12:43, Stephan Witt wrote: Am 01.08.2020 um 09:48 schrieb Daniel : I am trying to fix Ticket #9376. My attempt so far is attached. However, I have hit a little road block in that the clang compiler does not give me useful information (for me at least): CXXLDlyx Undefined symbols for architecture x86_64: "std::__1::basic_string, std::__1::allocator > lyx::convert, std::__1::allocator >, lyx::Length>(lyx::Length)", referenced from: lyx::LyXRC::write(std::__1::basic_ostream >&, bool, std::__1::basic_string, std::__1::allocator > const&) const in liblyxcore.a(LyXRC.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) 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 ERROR: Cannot build and install lyx for x86_64. Maybe someone knows what I might be doing wrong? IMO, it’s the change from int for full_screen_width to Length for screen_width. In LyXRC::write() the operator << is not implemented for Length, probably. Sounds plausible. So, short of implementing << for length, I should probably store the length in some other format, like string. Length seems to have a function for that: asString(). Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX-Code layout
On 2020-08-01 08:36, Richard Kimberly Heck wrote: On 7/25/20 12:26 AM, Daniel wrote: Is there a reason why the "LyX-Code" layout is not just called "Code"? I seem remember that "Labeling" used to be called LyX-List but was probably changed due to the confusing name. I guess "LyX-Code" is similarly confusing. (Is it some kind of code relevant to LyX only? one might wonder.) Probably like "ERT", I'll guess. Historical. It seems to go back to at least 1.1.5. Which probably means that lots of people have some sentimental attachment to it. But maybe not. Riki I would expect the sentimental attachment to be in the ballpark of lyx-list. Were there any riots when the name was changed to labeling recently? Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: All layouts icons look like Default
On 2020-07-21 21:04, Stephan Witt wrote: Am 21.07.2020 um 06:31 schrieb Daniel mailto:xraco...@gmx.de>>: In my copy of master all layout icons look like the Default icon. Anyone else seeing this (attached)? Daniel — No, not on my system. Stephan Thanks. Okay, maybe I just got a bad egg then. I'll try to update via git. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Compiling and using master on macOS
On 2020-07-08 08:28, Stephan Witt wrote:
Am 07.07.2020 um 07:35 schrieb Daniel :
On 2020-07-07 07:30, Daniel wrote:
On 2020-07-07 00:24, Stephan Witt wrote:
Am 06.07.2020 um 09:59 schrieb Daniel :
On 2020-03-15 21:37, Stephan Witt wrote:
Am 15.03.2020 um 17:16 schrieb Daniel :
Hi,
I am about to try compiling and using master on macOS. I just has a look at
INSTALL.MacOSX. It mentions Qt version 4. That seems a bit outdated. But I
guess that I am looking at the latest guide to compile on macOS, right?
Yes, it’s outdated. It should work with Qt4 - but Qt4 cannot be used on recent
macOS.
Basically I’m using the script LyX-Mac-binary-release.sh in development folder.
That’s much easier than other options, IMO.
First step is to install Xcode and the automake and/or cmake utilities. This
can be done with macports or homebrew. I’m using macports.
Second step is to get Qt5 - as source or binary distribution. I’m using the
source tarball and build Qt5 myself.
Optional components are the spell checker and libmagic frameworks.
Finally I start development/LyX-Mac-binary-release.sh with
--enable-cxx11
--with-qt-dir=/path/to/qt5
Stephan
Thanks. Finally came around trying it on macOS. I take it one has to run the
last command with sh, right? So, from the lyx directory (in the lyxgit
directory) I execute
sh development/LyX-Mac-binary-release.sh --enable-cxx11
--with-qt-dir=/Users//Qt/5.9.9
(where I replace by my macOS user name. Unfortunately, I get the
following:
: command not found-binary-release.sh: line 2:
: command not found-binary-release.sh: line 4:
: command not found-binary-release.sh: line 9:
: command not found-binary-release.sh: line 19:
: command not found-binary-release.sh: line 23:
: command not found-binary-release.sh: line 27:
': not a valid identifiery-release.sh: line 28: unset: `LD_LIBRARY_PATH
: command not found-binary-release.sh: line 29:
: command not found-binary-release.sh: line 44:
: command not found-binary-release.sh: line 49:
development/LyX-Mac-binary-release.sh: line 53: syntax error near unexpected
tok'n `in
'evelopment/LyX-Mac-binary-release.sh: line 53: `case "${QtVersion}:${QtAPI}" in
By the way, if finally successful, where will this put the LyX.app?
Daniel
I’ve made a protocol of the steps I took to build the package on a new system.
See the attached log. Probably the crucial thing is the mklyx-2.3.4.3.sh script.
I’m used to configure and build LyX out of source. I have a working directory
with one or more versions of LyX source code and a directory lyx-build for the
results. For Qt I have a source directory and an install target in parallel,
the build directory is in lyx-build.
$ ls /Users/Shared/LyX
lyx-2.3.4.3 (source)
lyx-2.3.5.2 (source)
lyx-build (directory)
qt-5.9.9-frameworks-cocoa-x86_64 (QTDIR for 5.9.9)
qt-everywhere-opensource-src-5.9.9 (source)
The lyx-build contains the build directory, the installed package (LyX.app) and
the resulting disk image.
$ ls /Users/Shared/LyX/
LyX-2.3.4.3+qt5-x86_64-cocoa.dmg (disk image)
LyX-2.3.4.3.app (working app)
LyX-2.3.4.3.build (binaries)
LyX-2.3.5.2+qt5-x86_64-cocoa.dmg (disk image)
LyX-2.3.5.2.app (working app)
LyX-2.3.5.2.build (binaries)
qt-5.9.9-build-x86_64 (binaries)
The /bin/sh on a Mac is in fact a bash, IMO.
Stephan
I am using git to download the lyx source and qt installer. But the steps
should be the same except for the unpacking and setting my own directories,
right?
Also what does
osascript -e 'tell application "Finder" to display notification "LyX is great
stuff"'
do? It looks strange.
Daniel
Okay, I guess it can't be the same because there is a specific LyX version
mentioned (2.3.4.3). What would I use if I want to compile from git (master)?
Yes, that’s true - this is the build from the shipped tar file for 2.3.4.3. But
it works for git clones too.
The difference to master is the name of the directory and this is your choice.
I’m using „lyx“ for it. I have another git clone for stable named „lyx-2.3.x“.
The resulting applications are placed in lyx-build and named according to the
AC_INIT macro in configure.ac (e.g. LyX,2.4.0dev => LyX-2.4.0dev.app).
In case you want to do the single steps w/o the build script you may try the
following:
1. create a dedicated build dir - e.g. lyx-build/master
2. create or update the configure script - run autogen.sh in your git checkout
(in place)
In this step I get:
% sh autogen.sh
: command not found
: command not found
: command not found:
'utogen.sh: line 18: syntax error near unexpected token `in
'utogen.sh: line 18: `case $automake_version in
I guess it does not fails for some reason?
Daniel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Searching reports
On 2020-04-19 19:33, Richard Kimberly Heck wrote: On 4/19/20 1:27 PM, Stephan Witt wrote: Am 19.04.2020 um 17:42 schrieb racoon : On 2020-04-19 17:22, Richard Kimberly Heck wrote: On 4/19/20 6:47 AM, Daniel wrote: Seemingly reasonable searches in the general search field in trac fail. For example, I was searching for an author name, a word in the summary, and the component name: "racoon spacing mathed" (https://www.lyx.org/trac/search?q=racoon+spacing+mathed). However, it did not return a result even though the combination of these exists (https://www.lyx.org/trac/ticket/11845). Removing the component name, kind of solved the problem. If you want to search for a component name, you need to use an Custom Query and add the component combo box. Same for author. That gives: https://www.lyx.org/trac/query?summary=~spacing=mathed=~racoon which returns #11845 and #11827. (The tilde means 'contains'.) By the way, since you have so many bug reports, you might want to set up a custom page to track them, as I have here: https://www.lyx.org/trac/wiki/HomeRikiHeck (Learned this trick from Vincent.) You just start by going to e.g.: https://www.lyx.org/trac/wiki/HomeRacoon and then you can create and edit the page. Look at the code for mine, or https://www.lyx.org/trac/wiki/BugTrackerHome to see how to do it. Riki Thanks. My example was a bit too simple. The problem with the custom query is that the summary is only searched for the exact sequence of words. That's why I started using the general search field. I don't think that it is worth doing much about it as long as one is aware of the limitations. You may choose the summary field more than once in search conditions. In that case it’s combined with OR. Yes, but I think he wants it combined with AND. You can't get that effect in 0.12.x, at least. Yes, I actually wanted AND. In search engines one just types several words and they are automatically combined with AND. If one wants furthermore to match a specific order of words one can use quotation marks. That seems to be working in the general search field but not in the custom search. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Searching reports
On 2020-04-19 17:22, Richard Kimberly Heck wrote: On 4/19/20 6:47 AM, Daniel wrote: Seemingly reasonable searches in the general search field in trac fail. For example, I was searching for an author name, a word in the summary, and the component name: "racoon spacing mathed" (https://www.lyx.org/trac/search?q=racoon+spacing+mathed). However, it did not return a result even though the combination of these exists (https://www.lyx.org/trac/ticket/11845). Removing the component name, kind of solved the problem. If you want to search for a component name, you need to use an Custom Query and add the component combo box. Same for author. That gives: https://www.lyx.org/trac/query?summary=~spacing=mathed=~racoon which returns #11845 and #11827. (The tilde means 'contains'.) By the way, since you have so many bug reports, you might want to set up a custom page to track them, as I have here: https://www.lyx.org/trac/wiki/HomeRikiHeck (Learned this trick from Vincent.) You just start by going to e.g.: https://www.lyx.org/trac/wiki/HomeRacoon and then you can create and edit the page. Look at the code for mine, or https://www.lyx.org/trac/wiki/BugTrackerHome to see how to do it. Riki Thanks. My example was a bit too simple. The problem with the custom query is that the summary is only searched for the exact sequence of words. That's why I started using the general search field. I don't think that it is worth doing much about it as long as one is aware of the limitations. I'll check the suggestion about the Home tracker. 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-10 22:02, Richard Kimberly Heck wrote: 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 I see. I am not sure what is the super hard part. Is it to get the idea right or the implementation or both? If getting the idea right, then the label breaking that I was suggesting before, seems much less tricky because it's basically just normally broken text with a background color (the button color). On the more complicated inset issue: I guess the idea you suggested is most sensible in the case the inset contains only a single line and floats in the text, which might be the case often enough. But it is not clear to me that it is sensible for multi-line insets, such as footnotes, since a non broken inset gives a better idea of what the footnote would look like. Here is another rough idea for improvement of insets whose content is not supposed to float in the text, such as footnotes. Leave the label floating in the normal text line and open the inset below: ++ Here is some text. Here is| FOOTNOTE 1 | some text. Here is some text. +-++-+ | This is the text of the footnote, which goes across a few lines, | | and is NOT broken in a sensible way. | ++ Here is some text. Here is some text. However, if there is more than one open inset in a line, then the breaking becomes less nice, but I think it's still pretty readable: ++ Here is some text. Here is| FOOTNOTE 1 | +-++-+ | This is the text of the footnote, which goes across a few lines, | | and is NOT broken in a sensible way. | ++ ++ | FOOTNOTE 2 | some text. Here is some text. Here is some text. Here is ++---+ | This is the text of the footnote, which goes across a few lines, | | and is NOT broken in a sensible way. | ++ some text. Just a thought. Not perfect. 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-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: Save on save
On 2020-03-28 20:16, Richard Kimberly Heck wrote: On 3/28/20 3:00 PM, Richard Kimberly Heck wrote: On 3/28/20 2:55 PM, Daniel wrote: On 2020-03-28 19:47, Richard Kimberly Heck wrote: On 3/28/20 5:17 AM, Daniel wrote: On 2020-03-28 04:27, Richard Kimberly Heck wrote: On 3/27/20 2:48 PM, racoon wrote: On 2020-03-27 19:25, Richard Kimberly Heck wrote: On 3/27/20 2:21 PM, racoon wrote: On 2020-03-27 17:52, racoon wrote: On 2020-03-27 17:41, Richard Kimberly Heck wrote: On 3/27/20 4:21 AM, Daniel wrote: On 2020-03-19 15:03, racoon wrote: On 2020-03-19 14:53, Richard Kimberly Heck wrote: Yes, you could assign something like "command-sequence self-insert s; char-delete-backward; buffer-write" to Ctrl-S. Undo won't work, because then the document isn't dirty again. Riki Unfortunately, when the settings dialog is closed and re-opened everything that comes after the first semi-colon is chopped off. Is that a bug? Oddly enough, it is possible to use similar command sequences. So, the problem isn't general. For example, command-sequence self-insert .; space-insert normal just works fine (see https://www.lyx.org/trac/ticket/11798#comment:6). I don't know what the difference might be. Don't see it here. You can put it manually into your user.bind file if need be. Riki Thanks, that helped. And I figured out what the problem was. I copied the command from your email not knowing that my email program had inserted a line-break after the first command in the sequence. Unfortunately, the input box in the shortcut editor masked this. I guess it would be better if text pasted into the input box was cleaned of characters it does not support rather than just hiding them. Daniel Seems like at least this particular command sequence is not such a good idea. I just realized that it wrecks havoc if there is an active selection of text because the text gets removed. Try adding "escape" first. That clears the selection. Of course, you lose the selection. Riki Thanks. That works better. Yes, losing the selection isn't perfect. Btw. the action input field suffers from the same problem as the shortcut editor, e.g. it masks line-breaks which make a command fail. I don't know if there is any easy solution to this. I think I'd regard it as a Qt bug. Riki Yes, might be a bug. I have checked the input fields in Scribus and they exhibit the same problem. However, as far as I understood, there is a function to determine which characters are valid input. Maybe that helps? Here is an example: https://doc.qt.io/qt-5/qregexpvalidator.html#details Maybe one could set the validator to a regex that does not match any newline (\n) or return (\r)? But I don't know enough about Qt or regex. It wouldn't really help. That would prevent you from actually saving the shortcut, but you'd be totally stumped why. (Well, not you, but most users.) Riki Okay, then I seem to have misunderstood what the validator is doing. "Sets this line edit to only accept input that the validator, v, will accept." (https://doc.qt.io/qt-5/qlineedit.html#setValidator) That sounded to me as if the *input* would be limited. And I'd hoped that on paste the characters would be stripped (or the string cut off at the first occurrence). Yes, sorry. In that case, it wouldn't let you paste it at all. Maybe that's better, though. Hmm. In some cases, it won't let you paste, but using our NoNewLineValidator, it does, and it just removes the CR. Riki Sounds promising, or? I hope there is a way to apply it across the board to all qLineEdits. Seems like an oversight that Qt hasn't set it as default. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On 2020-03-27 19:25, Richard Kimberly Heck wrote: On 3/27/20 2:21 PM, racoon wrote: On 2020-03-27 17:52, racoon wrote: On 2020-03-27 17:41, Richard Kimberly Heck wrote: On 3/27/20 4:21 AM, Daniel wrote: On 2020-03-19 15:03, racoon wrote: On 2020-03-19 14:53, Richard Kimberly Heck wrote: Yes, you could assign something like "command-sequence self-insert s; char-delete-backward; buffer-write" to Ctrl-S. Undo won't work, because then the document isn't dirty again. Riki Unfortunately, when the settings dialog is closed and re-opened everything that comes after the first semi-colon is chopped off. Is that a bug? Oddly enough, it is possible to use similar command sequences. So, the problem isn't general. For example, command-sequence self-insert .; space-insert normal just works fine (see https://www.lyx.org/trac/ticket/11798#comment:6). I don't know what the difference might be. Don't see it here. You can put it manually into your user.bind file if need be. Riki Thanks, that helped. And I figured out what the problem was. I copied the command from your email not knowing that my email program had inserted a line-break after the first command in the sequence. Unfortunately, the input box in the shortcut editor masked this. I guess it would be better if text pasted into the input box was cleaned of characters it does not support rather than just hiding them. Daniel Seems like at least this particular command sequence is not such a good idea. I just realized that it wrecks havoc if there is an active selection of text because the text gets removed. Try adding "escape" first. That clears the selection. Of course, you lose the selection. Riki Thanks. That works better. Yes, losing the selection isn't perfect. Btw. the action input field suffers from the same problem as the shortcut editor, e.g. it masks line-breaks which make a command fail. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On 2020-03-27 17:52, racoon wrote: On 2020-03-27 17:41, Richard Kimberly Heck wrote: On 3/27/20 4:21 AM, Daniel wrote: On 2020-03-19 15:03, racoon wrote: On 2020-03-19 14:53, Richard Kimberly Heck wrote: Yes, you could assign something like "command-sequence self-insert s; char-delete-backward; buffer-write" to Ctrl-S. Undo won't work, because then the document isn't dirty again. Riki Unfortunately, when the settings dialog is closed and re-opened everything that comes after the first semi-colon is chopped off. Is that a bug? Oddly enough, it is possible to use similar command sequences. So, the problem isn't general. For example, command-sequence self-insert .; space-insert normal just works fine (see https://www.lyx.org/trac/ticket/11798#comment:6). I don't know what the difference might be. Don't see it here. You can put it manually into your user.bind file if need be. Riki Thanks, that helped. And I figured out what the problem was. I copied the command from your email not knowing that my email program had inserted a line-break after the first command in the sequence. Unfortunately, the input box in the shortcut editor masked this. I guess it would be better if text pasted into the input box was cleaned of characters it does not support rather than just hiding them. Daniel Seems like at least this particular command sequence is not such a good idea. I just realized that it wrecks havoc if there is an active selection of text because the text gets removed. But it seems any change to the document will likely have an effect cannot be easily reverted by a another command. This does not only concern deleted text but also added tracked changes, e.g. by inserting an inset. So, I guess there is no way to get this without proper implementation, right? Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On 2020-03-27 17:41, Richard Kimberly Heck wrote: On 3/27/20 4:21 AM, Daniel wrote: On 2020-03-19 15:03, racoon wrote: On 2020-03-19 14:53, Richard Kimberly Heck wrote: Yes, you could assign something like "command-sequence self-insert s; char-delete-backward; buffer-write" to Ctrl-S. Undo won't work, because then the document isn't dirty again. Riki Unfortunately, when the settings dialog is closed and re-opened everything that comes after the first semi-colon is chopped off. Is that a bug? Oddly enough, it is possible to use similar command sequences. So, the problem isn't general. For example, command-sequence self-insert .; space-insert normal just works fine (see https://www.lyx.org/trac/ticket/11798#comment:6). I don't know what the difference might be. Don't see it here. You can put it manually into your user.bind file if need be. Riki Thanks, that helped. And I figured out what the problem was. I copied the command from your email not knowing that my email program had inserted a line-break after the first command in the sequence. Unfortunately, the input box in the shortcut editor masked this. I guess it would be better if text pasted into the input box was cleaned of characters it does not support rather than just hiding them. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On 2020-03-19 15:21, Scott Kostyshak wrote: On Thu, Mar 19, 2020 at 03:14:00PM +0100, racoon wrote: On 2020-03-19 15:08, Scott Kostyshak wrote: On Thu, Mar 19, 2020 at 09:53:19AM -0400, Richard Kimberly Heck wrote: On 3/19/20 9:46 AM, racoon wrote: On 2020-03-19 14:43, Richard Kimberly Heck wrote: On 3/19/20 5:43 AM, Daniel wrote: All applications (Libre Writer, Pages, Visual Studio Code, TextEdit, etc.) I tested save my documents whenever I press ctrl|cmd+S or choose Save from the menu. This can be seen, for example, from the modified date being updated. The only exception are MS office (which does not save and not gray out the Save menu) and LyX (which does not save but does at least gray out the Save menu). Is there a particular reason LyX behaves in this way? Is there a way, I can change this behavior and force a save? You mean if the document is not dirty? Hit "s", backspace, then save. I.e, make it dirty. Riki I find it hard to remember doing this. So, I would like to change LyX's Save command to a forced saving. Maybe there is a nice command sequence that renders the document dirty, maybe via some change; undoes the change, if there was one made; saves? Yes, you could assign something like "command-sequence self-insert s; char-delete-backward; buffer-write" to Ctrl-S. Undo won't work, because then the document isn't dirty again. It's always useful to have a use case for motivation. racoon, what is your use case? I've come across this when I wanted to do something like open a 2.2.x file in 2.3.x and save it just to update the file format. I then commit those changes in git, and then I make a change. That ways I separate out the format update from the change. Scott My use case is that I often change the closed/open state of insets which does not render the document dirty. But I still want LyX to remember these changes. And I often forget to render it artificially dirty before saving. Ah, that makes sense. I now remember having the same issue (closing/opening insets). Bold move: https://www.lyx.org/trac/ticket/2993#comment:13. Feel free to close again. :) Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On 2020-03-19 14:53, Richard Kimberly Heck wrote: On 3/19/20 9:46 AM, racoon wrote: On 2020-03-19 14:43, Richard Kimberly Heck wrote: On 3/19/20 5:43 AM, Daniel wrote: All applications (Libre Writer, Pages, Visual Studio Code, TextEdit, etc.) I tested save my documents whenever I press ctrl|cmd+S or choose Save from the menu. This can be seen, for example, from the modified date being updated. The only exception are MS office (which does not save and not gray out the Save menu) and LyX (which does not save but does at least gray out the Save menu). Is there a particular reason LyX behaves in this way? Is there a way, I can change this behavior and force a save? You mean if the document is not dirty? Hit "s", backspace, then save. I.e, make it dirty. Riki I find it hard to remember doing this. So, I would like to change LyX's Save command to a forced saving. Maybe there is a nice command sequence that renders the document dirty, maybe via some change; undoes the change, if there was one made; saves? Yes, you could assign something like "command-sequence self-insert s; char-delete-backward; buffer-write" to Ctrl-S. Undo won't work, because then the document isn't dirty again. Riki Unfortunately, when the settings dialog is closed and re-opened everything that comes after the first semi-colon is chopped off. Is that a bug? Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On 2020-03-19 14:43, Richard Kimberly Heck wrote: On 3/19/20 5:43 AM, Daniel wrote: All applications (Libre Writer, Pages, Visual Studio Code, TextEdit, etc.) I tested save my documents whenever I press ctrl|cmd+S or choose Save from the menu. This can be seen, for example, from the modified date being updated. The only exception are MS office (which does not save and not gray out the Save menu) and LyX (which does not save but does at least gray out the Save menu). Is there a particular reason LyX behaves in this way? Is there a way, I can change this behavior and force a save? You mean if the document is not dirty? Hit "s", backspace, then save. I.e, make it dirty. Riki I find it hard to remember doing this. So, I would like to change LyX's Save command to a forced saving. Maybe there is a nice command sequence that renders the document dirty, maybe via some change; undoes the change, if there was one made; saves? Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On 2020-03-19 15:08, Scott Kostyshak wrote: On Thu, Mar 19, 2020 at 09:53:19AM -0400, Richard Kimberly Heck wrote: On 3/19/20 9:46 AM, racoon wrote: On 2020-03-19 14:43, Richard Kimberly Heck wrote: On 3/19/20 5:43 AM, Daniel wrote: All applications (Libre Writer, Pages, Visual Studio Code, TextEdit, etc.) I tested save my documents whenever I press ctrl|cmd+S or choose Save from the menu. This can be seen, for example, from the modified date being updated. The only exception are MS office (which does not save and not gray out the Save menu) and LyX (which does not save but does at least gray out the Save menu). Is there a particular reason LyX behaves in this way? Is there a way, I can change this behavior and force a save? You mean if the document is not dirty? Hit "s", backspace, then save. I.e, make it dirty. Riki I find it hard to remember doing this. So, I would like to change LyX's Save command to a forced saving. Maybe there is a nice command sequence that renders the document dirty, maybe via some change; undoes the change, if there was one made; saves? Yes, you could assign something like "command-sequence self-insert s; char-delete-backward; buffer-write" to Ctrl-S. Undo won't work, because then the document isn't dirty again. It's always useful to have a use case for motivation. racoon, what is your use case? I've come across this when I wanted to do something like open a 2.2.x file in 2.3.x and save it just to update the file format. I then commit those changes in git, and then I make a change. That ways I separate out the format update from the change. Scott My use case is that I often change the closed/open state of insets which does not render the document dirty. But I still want LyX to remember these changes. And I often forget to render it artificially dirty before saving. (For some reasons my RE posts get a "Is being held until the list moderator can review it for approval.") Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Problem with message "The file ... changed on disk."
On 08/04/2018 04:17, Richard Kimberly Heck wrote: On 04/07/2018 06:13 PM, Scott Kostyshak wrote: On Fri, Apr 06, 2018 at 10:47:29PM +, Richard Kimberly Heck wrote: On 04/06/2018 04:03 AM, racoon wrote: Hi, I am getting the message "The file ... changed on disk." even though I just saved the file a minute ago or so and it isn't opened anywhere else. My hunch is that it relates to the syncing with Spider Oak. Did anyone experience a similar problem or know what's going on? That seems likely. Did the timestamp change? Not sure how useful it is, but I tested (on Linux) and if I have the .lyx file open and just use the touch command externally, I am not given the message. Wild guess on my part, and apparently not a good one. I suppose the first thing to do is to turn off Spider Oak's autosync and see if that makes the problem go away. With Spider Oak tuned off I did not get the messages and they reappeared once it was turned on again. Daniel
Re: Problem with message "The file ... changed on disk."
On 16/04/2018 21:01, Richard Kimberly Heck wrote: On 04/14/2018 05:38 PM, Scott Kostyshak wrote: On Sun, Apr 08, 2018 at 02:17:22AM +, Richard Kimberly Heck wrote: I suppose the first thing to do is to turn off Spider Oak's autosync and see if that makes the problem go away. Racoon, does the above make the problem go away? It would be nice to know, just make sure that this is the problem. Also, after a Spider Oak sync, can you check the properties of the .lyx file. Do they change, compared to before a Spider Oak sync? Are you sure that the .lyx file before/after a Spider Oak sync is identical? How did you check? Part of the reason I'd asked about that I often seem to get surprise recompilations when switching between git branches, even though timestamps and files should not have changed. I am not using any versioning system, if that was your question. Daniel
Re: Problem with message "The file ... changed on disk."
On 14/04/2018 23:38, Scott Kostyshak wrote: On Sun, Apr 08, 2018 at 02:17:22AM +, Richard Kimberly Heck wrote: I suppose the first thing to do is to turn off Spider Oak's autosync and see if that makes the problem go away. Racoon, does the above make the problem go away? It would be nice to know, just make sure that this is the problem. Also, after a Spider Oak sync, can you check the properties of the .lyx file. Do they change, compared to before a Spider Oak sync? Are you sure that the .lyx file before/after a Spider Oak sync is identical? How did you check? I didn't check. I have no idea how to check. I was just guessing what the cause might be since Spider Oak is the only other application that does something with the files I am using. Daniel
Re: Problem with message "The file ... changed on disk."
On 09/04/2018 17:36, Kornel Benko wrote: Am Samstag, 7. April 2018 22:17:22 CEST schrieb Richard Kimberly Heck <rikih...@lyx.org>: On 04/07/2018 06:13 PM, Scott Kostyshak wrote: On Fri, Apr 06, 2018 at 10:47:29PM +, Richard Kimberly Heck wrote: On 04/06/2018 04:03 AM, racoon wrote: Hi, I am getting the message "The file ... changed on disk." even though I just saved the file a minute ago or so and it isn't opened anywhere else. My hunch is that it relates to the syncing with Spider Oak. Did anyone experience a similar problem or know what's going on? That seems likely. Did the timestamp change? Not sure how useful it is, but I tested (on Linux) and if I have the .lyx file open and just use the touch command externally, I am not given the message. Wild guess on my part, and apparently not a good one. I suppose the first thing to do is to turn off Spider Oak's autosync and see if that makes the problem go away. All of this seems to use QFileSystemWatcher in the background, so we are beholden to whatever it thinks counts as a file change. A momentary renaming or whatever seems as if it could trigger that, from what I can tell, and that kind of thing might well happen during syncing. I wonder if even the locking and unlocking that has caused other problems might trigger it? Riki Suppose the time settings on this two computers are different. What would be used as time stamp, the one of the lyx-executable or the one on which the file is stored? I just wanted to say that LyX also asks me whether to overwrite the file after the "changed on disk" message is shown and I try to save. Maybe that helps in knowing what kind of change happened to the file. Not sure whether I can help somehow by testing something particular. Please let me know if so. Daniel
Re: Problem with message "The file ... changed on disk."
Do you happen to know whether there is a way to turn this feature in LyX off? On 07/04/2018 16:02, Richard Kimberly Heck wrote: On 04/07/2018 09:46 AM, racoon wrote: On 07/04/2018 15:42, Richard Kimberly Heck wrote: On 04/07/2018 04:31 AM, racoon wrote: On 07.04.2018 00:47, Richard Kimberly Heck wrote: On 04/06/2018 04:03 AM, racoon wrote: Hi, I am getting the message "The file ... changed on disk." even though I just saved the file a minute ago or so and it isn't opened anywhere else. My hunch is that it relates to the syncing with Spider Oak. Did anyone experience a similar problem or know what's going on? That seems likely. Did the timestamp change? I don't know how to figure that out. Wouldn't it be strange if syncing changes the timestamp? Not necessarily. It very much depends upon how Spider Oak is working. If it is not totally strange for a syncing app to work that way, does that mean LyX's check for file changes is problematic? Possibly. I think we may depend upon both the timestamp and a hash of the file, but I'm not sure. Riki
Re: Problem with message "The file ... changed on disk."
On 07/04/2018 15:42, Richard Kimberly Heck wrote: On 04/07/2018 04:31 AM, racoon wrote: On 07.04.2018 00:47, Richard Kimberly Heck wrote: On 04/06/2018 04:03 AM, racoon wrote: Hi, I am getting the message "The file ... changed on disk." even though I just saved the file a minute ago or so and it isn't opened anywhere else. My hunch is that it relates to the syncing with Spider Oak. Did anyone experience a similar problem or know what's going on? That seems likely. Did the timestamp change? I don't know how to figure that out. Wouldn't it be strange if syncing changes the timestamp? Not necessarily. It very much depends upon how Spider Oak is working. If it is not totally strange for a syncing app to work that way, does that mean LyX's check for file changes is problematic? Daniel
Re: Problem with message "The file ... changed on disk."
On 07.04.2018 00:47, Richard Kimberly Heck wrote: On 04/06/2018 04:03 AM, racoon wrote: Hi, I am getting the message "The file ... changed on disk." even though I just saved the file a minute ago or so and it isn't opened anywhere else. My hunch is that it relates to the syncing with Spider Oak. Did anyone experience a similar problem or know what's going on? That seems likely. Did the timestamp change? I don't know how to figure that out. Wouldn't it be strange if syncing changes the timestamp? Daniel
Re: Update on 2.3.0 situation and Windows-specific issues
On 06.04.2018 11:18, Jean-Marc Lasgouttes wrote: Le 06/04/2018 à 00:40, Uwe Stöhr a écrit : Am 05.04.2018 um 04:47 schrieb Scott Kostyshak: In my opinion it is that important, because updating LyX could break something else on a user's computer. No! Why do you claim this again? Don't mix potential bugs in a LaTeX package on CTAN with LyX. With this argumentation every package update could introduce bugs. LyX is not responsible for bugs on CTAN. Aren't we discussing bugs in miktex here? CTAN is a different beast, although living on the bleeding edge is probably a bad decision for "average" users. Yet another attempt to clarify a bit (maybe just for me): I was hoping the discussion moved past the point discussed above. If not, we should first try to answer the following question: (Q1) Does installing a new version of (or update) MiKTeX can break the compilation of LaTeX documents that were compiled fine before (because it can introduce bugs that an already installed previous version did not have)? It seemed to me that there is agreement on this. Please correct me if I am wrong. Only because (Q1) can be affirmed, the second question became important: (Q2) During installation, should there be a question asking the user whether to update (and, alternatively), cancel the installation? At least two principled approaches have been suggested: First, what I call *the consent approach*: Yes to Q2, because LyX should not do without consent what can break documents that compiled fine before. If I see it correctly, this approach was applied in previous version where the user could decline an update of MiKTeX (though it was recommended to update). Second, what I call *the silent approach*: No to Q2, because the LyX installation should automatically do what is best for (most?) unexperienced users and a dialog could confuse them. Now, if I see it correctly, the matter to decide the issue is one of importance. It's a value judgment. And there is no dominant approach that is better in all respects. Notice also that one can find both what is best for unexperienced users *and* not to break documents that compiled fine before valuable. It is just that one comes out on one or the other side because of an overall judgment, a favorable combination of these values. In so far, I think no side is being stupid by overlooking an totally obviously better approach. If this is correct, I think it is very important that everyone sees this since it helps both to understand the other side and not to feel like others think that one is just being stupid. Some have tried to lessen the strength of the reasons in favor of the silent approach by making the dialog easier to understand. If this would be fully successful, then the consent approach could come closer to being dominant in all respects. (For example, Scott is following this line.) On the other hand, it might be possible to lessen the reason in favor of the consent approach, for example, if MiKTex updates almost never break a LaTeX system. This might be doubted given the reason the current problem was arrived at. I see the following ways forward: 1. Further trying to discuss the basic values at stake and see whether one approach comes out - even if not in all respects - overall favorable. (For example, Uwe and Jean-Marc are following this approach by discussing analogue cases, like starting a car.) 2. Act on a set of basic principles (like a charter) the LyX development should follow, if there is one. Maybe there is a rule like: Never do anything without consent that could break the LaTeX compilation, or always do what is best for the unexperienced user. 3. Use some collective method of decision making common in democracies, like majority or two-thirds majority (among developers). And then just act on it together. Obviously, decision making using vetoes would not work at the moment. All other alternatives I can think of are kind of sad... but maybe I overlooked something. Best, Daniel
Problem with message "The file ... changed on disk."
Hi, I am getting the message "The file ... changed on disk." even though I just saved the file a minute ago or so and it isn't opened anywhere else. My hunch is that it relates to the syncing with Spider Oak. Did anyone experience a similar problem or know what's going on? As a fix I can just click on "Ignore" but it is a bit annoying. Best, Daniel
Re: SVG figure wrong preview size
On 03.04.2018 17:57, racoon wrote: Hi, I still get some strange previews with SVG figure (external material), see "wrong size.png". It looks like the svg content and the text are applied in different sizes. This happens with ps output but not with pdflatex, see "wrong size output with ps2pdf.png" and "right size with pdflatex.png", respectively. I have also attached the svg if you want to try it yourself. ps. It might look a bit different for you since I realized that I have an '--export-area-page' in my svg2pstex.py. However, even without it the preview and output with ps is way off.
SVG figure wrong preview size
Hi, I still get some strange previews with SVG figure (external material), see "wrong size.png". It looks like the svg content and the text are applied in different sizes. This happens with ps output but not with pdflatex, see "wrong size output with ps2pdf.png" and "right size with pdflatex.png", respectively. I have also attached the svg if you want to try it yourself. Best, Daniel
Re: Tab stop width in Preamble
On 02.04.2018 21:31, Richard Kimberly Heck wrote: On 04/02/2018 06:08 AM, racoon wrote: On 27.03.2018 11:16, racoon wrote: On 27.03.2018 11:11, racoon wrote: Hi, Could it be that the tab stop width in the preamble is 12 spaces wide? That seems an awful lot to me. Is there a way to change it something narrower, like 2 spaces? The same applies to ERTs. They have a tab stop of 4 spaces. Can that be changed to 2 spaces? (And maybe preamble and ERT tab stops should be the same in general?) I've found a couple of links concerning setting the tab stop width. Maybe someone knows how to use them. I've committed this to master and to 2.3.2-staging for the preamble, set to four spaces, which seems to work pretty well. If you want to change it elsewhere, have a look at b4d885ac for the code. There is actually at least one more instance where a smaller tab stop might be good: the code preview. Daniel
Re: Tab stop width in Preamble
On 02.04.2018 21:31, Richard Kimberly Heck wrote: On 04/02/2018 06:08 AM, racoon wrote: On 27.03.2018 11:16, racoon wrote: On 27.03.2018 11:11, racoon wrote: Hi, Could it be that the tab stop width in the preamble is 12 spaces wide? That seems an awful lot to me. Is there a way to change it something narrower, like 2 spaces? The same applies to ERTs. They have a tab stop of 4 spaces. Can that be changed to 2 spaces? (And maybe preamble and ERT tab stops should be the same in general?) I've found a couple of links concerning setting the tab stop width. Maybe someone knows how to use them. I've committed this to master and to 2.3.2-staging for the preamble, set to four spaces, which seems to work pretty well. If you want to change it elsewhere, have a look at b4d885ac for the code. Thanks! Daniel
Re: Tab stop width in Preamble
On 27.03.2018 11:16, racoon wrote: On 27.03.2018 11:11, racoon wrote: Hi, Could it be that the tab stop width in the preamble is 12 spaces wide? That seems an awful lot to me. Is there a way to change it something narrower, like 2 spaces? The same applies to ERTs. They have a tab stop of 4 spaces. Can that be changed to 2 spaces? (And maybe preamble and ERT tab stops should be the same in general?) I've found a couple of links concerning setting the tab stop width. Maybe someone knows how to use them. I guess at least the Preamble should set to a smaller tab stop width, like 4 spaces which would be the same as in ERTs. http://www.qtcentre.org/threads/10253-setTabStopWidth-doesn-t-work?s=8a66c7e7178cf45ad9d36db4b73a9316=54413#post54413 https://stackoverflow.com/questions/13027091/how-to-override-tab-width-in-qt#15247253 http://doc.qt.io/archives/qt-4.8/qtextedit.html#tabStopWidth-prop
Re: Poll: change "foot x" too "fn x"
On 31.03.2018 15:45, Joel Kulesza wrote: I regret that continually sending URLs about what "fn" means will not change my mind that (a) fn comes first as "function" and (b) foot->fn is an improvement. Abbreviations are contextual and these links feel like selection bias to me. Clearly, by just using two letters one can mean a lot of things (my own Google'd URL: https://www.abbreviations.com/FN). Yes, I agree context is important. That is why I send the scholarly texts which LyX is clearly related to. Further, I wonder how translations of just the two letters would work. I don't think English abbreviations on labels should be chosen based on whether they work in other languages as well. It would also be a pretty tricky aim given the variety in languages. To the remark: Yes, "footnote" might be better than "foot". But I think there is reason to prefer a short labels since labels clutter the text. Hence, I suggest "fn" or, maybe, "fn.". I wonder why you think brevity is preferable to clarity. I suspect "foot" was attempting to strike a balance. I'd rather see no change than moving too hard in one direction (brevity) versus the other. The argument was not based on brevity alone. (Though I still consider it a virtue.) There was also the reason for "fn" being a common abbreviation for footnote in texts while "foot" is none. Hence, also, my favoring "footnote" over "foot". Further, regarding context: because LaTeX can and is used with mathematics, "fn" could easily be misunderstood as function by a new user and not taken immediately as a footnote even by an experienced one if collapsable mathematical insets were to be used. I don't think "fn" is a common abbreviation for function in mathematics. At least I can't remember having come across it in my studies. Do you have any evidence? The only place I see "Fn" is right in front of me on my keyboard. There it actually stands for "function", so that might be where the connection is coming from. But it is not mathematical at all. Still the connection might be made by enough people. I don't know that. Daniel P.S. Said in jest: it's interesting to have a conversation with someone on how to properly name/identify something who goes by the handle "racoon". I imagine a character from Guardians of the Galaxy on the far end of this email (https://en.wikipedia.org/wiki/Rocket_Raccoon). I am just too lazy to change my sender address. Notice the addition "c" though. Two more tries. :)
Re: Poll: change "foot x" too "fn x"
On 31.03.2018 12:34, racoon wrote: On 31.03.2018 12:33, racoon wrote: On 31.03.2018 12:23, racoon wrote: On 31.03.2018 00:03, Scott Kostyshak wrote: On Fri, Mar 30, 2018 at 06:00:06PM +, José Abílio Matos wrote: On Wednesday, 28 March 2018 20.26.52 WEST racoon wrote: I'd like to get your take on an enhancement request for changing the label for footnotes from "foot x" too "fn x". I think the latter is a much more common abbreviation than the former. I agree but for me fn remembers FuNction. :-) My first thought was of "function" also. Come on, there are so much more FUN abbreviations for function. ;) Here is some evidence that the abbreviation fn is actually used for footnotes: https://scholar.google.com/scholar?hl=en_sdt=0%2C5=%22see+fn%22= Wikipedia uses the fn abbreviation in the code: https://en.wikipedia.org/wiki/Help:Footnotes#Footnotes:_embedding_references https://en.wiktionary.org/wiki/fn https://www.merriam-webster.com/dictionary/fn https://en.oxforddictionaries.com/definition/us/fn. https://www.collinsdictionary.com/dictionary/english/fn https://www.encyclopedia.com/humanities/dictionaries-thesauruses-pictures-and-press-releases/fn https://www.quora.com/What-is-the-correct-abbreviation-for-footnote?share=1
Re: Poll: change "foot x" too "fn x"
On 31.03.2018 12:33, racoon wrote: On 31.03.2018 12:23, racoon wrote: On 31.03.2018 00:03, Scott Kostyshak wrote: On Fri, Mar 30, 2018 at 06:00:06PM +, José Abílio Matos wrote: On Wednesday, 28 March 2018 20.26.52 WEST racoon wrote: I'd like to get your take on an enhancement request for changing the label for footnotes from "foot x" too "fn x". I think the latter is a much more common abbreviation than the former. I agree but for me fn remembers FuNction. :-) My first thought was of "function" also. Come on, there are so much more FUN abbreviations for function. ;) Here is some evidence that the abbreviation fn is actually used for footnotes: https://scholar.google.com/scholar?hl=en_sdt=0%2C5=%22see+fn%22= Wikipedia uses the fn abbreviation in the code: https://en.wikipedia.org/wiki/Help:Footnotes#Footnotes:_embedding_references https://en.wiktionary.org/wiki/fn Daniel
Re: Poll: change "foot x" too "fn x"
On 31.03.2018 12:23, racoon wrote: On 31.03.2018 00:03, Scott Kostyshak wrote: On Fri, Mar 30, 2018 at 06:00:06PM +, José Abílio Matos wrote: On Wednesday, 28 March 2018 20.26.52 WEST racoon wrote: I'd like to get your take on an enhancement request for changing the label for footnotes from "foot x" too "fn x". I think the latter is a much more common abbreviation than the former. I agree but for me fn remembers FuNction. :-) My first thought was of "function" also. Come on, there are so much more FUN abbreviations for function. ;) Here is some evidence that the abbreviation fn is actually used for footnotes: https://scholar.google.com/scholar?hl=en_sdt=0%2C5=%22see+fn%22= Wikipedia uses the fn abbreviation in the code: https://en.wikipedia.org/wiki/Help:Footnotes#Footnotes:_embedding_references Daniel
Re: Poll: change "foot x" too "fn x"
On 31.03.2018 01:30, Joel Kulesza wrote: On Fri, Mar 30, 2018 at 4:03 PM, Scott Kostyshak <skost...@lyx.org <mailto:skost...@lyx.org>> wrote: On Fri, Mar 30, 2018 at 06:00:06PM +, José Abílio Matos wrote: > On Wednesday, 28 March 2018 20.26.52 <tel:2018%2020.26.52> WEST racoon wrote: > > I'd like to get your take on an enhancement request for changing the > > label for footnotes from "foot x" too "fn x". I think the latter is a > > much more common abbreviation than the former. > > I agree but for me fn remembers FuNction. :-) My first thought was of "function" also. "fn" is also function in my mind. Is "foot" too verbose? For clarity, why not "footnote"? Yes, "footnote" might be better than "foot". But I think there is reason to prefer a short labels since labels clutter the text. Hence, I suggest "fn" or, maybe, "fn.". Daniel
Re: Poll: change "foot x" too "fn x"
On 31.03.2018 00:03, Scott Kostyshak wrote: On Fri, Mar 30, 2018 at 06:00:06PM +, José Abílio Matos wrote: On Wednesday, 28 March 2018 20.26.52 WEST racoon wrote: I'd like to get your take on an enhancement request for changing the label for footnotes from "foot x" too "fn x". I think the latter is a much more common abbreviation than the former. I agree but for me fn remembers FuNction. :-) My first thought was of "function" also. Come on, there are so much more FUN abbreviations for function. ;) Here is some evidence that the abbreviation fn is actually used for footnotes: https://scholar.google.com/scholar?hl=en_sdt=0%2C5=%22see+fn%22= Daniel
Poll: change "foot x" too "fn x"
I'd like to get your take on an enhancement request for changing the label for footnotes from "foot x" too "fn x". I think the latter is a much more common abbreviation than the former. https://www.lyx.org/trac/ticket/11092#comment:2 (Probably someone will tell me that it is actually from Latin or so. :) )
Re: Tab stop width in Preamble
On 27.03.2018 11:11, racoon wrote: Hi, Could it be that the tab stop width in the preamble is 12 spaces wide? That seems an awful lot to me. Is there a way to change it something narrower, like 2 spaces? The same applies to ERTs. They have a tab stop of 4 spaces. Can that be changed to 2 spaces? (And maybe preamble and ERT tab stops should be the same in general?) Daniel
Tab stop width in Preamble
Hi, Could it be that the tab stop width in the preamble is 12 spaces wide? That seems an awful lot to me. Is there a way to change it something narrower, like 2 spaces? Daniel
Re: New Win installer ready for LyX 2.3.0
On 23.03.2018 10:33, Uwe Stöhr wrote: Am 23.03.2018 um 05:22 schrieb Scott Kostyshak: I understand your argument. I disagree that adding a dialog would hurt the vast majority more than it would help it That is the fundamental disagreement. It doesn't help if you ask users who knows what a package is, if they would understand such a dialog. My experience is that the majority of LyX users (under Windows of course) don't know this. My experience will not change the longer we discuss. People like my mother can and do use LyX. She would not understand what you want but she should be able to use LyX in future. Just an idea involving previous experience. I seem to remember that since I am using LyX, which goes back many versions, there was always a dialog recommending but *asking* the user to run the MiKTeX update. As I see it, due to the problems Uwe pointed out, many developers seem to accept that, at least for 2.3, LyX should not be installed without a forced MiKTeX update. (I might be wrong on this.) However, also many developers seem to agree that, *as in all the versions before*, there should be a dialog asking the user before making changes to MiKTeX. (If the user denies to update MiKTeX, LyX will not be installed. So any amateur user will finally answer the question affirmative, I believe.) Is there any strong evidence (maybe from many questions on the list or emails) that the dialog that LyX was showing before confused users? If not, what is the main difference between the old dialog and the new dialog in terms of how comprehensible it is? I don't claim that many developers will follow my reasoning here. It is just a desperate attempt to make progress in some way. Best, Daniel
Windows installer: install for all users
Hi, Under windows some installers ask the user whether the installation should be performed for all or only the current user. See for example: https://ca.nctu.edu.tw/images/how-to-use/2-ftp-client-installation/en-gb/2-Me_or_everyone.png With the current LyX installer one can only do one or the other depending on whether the installer is executed with administrator privileges or not. If it is feasible, I think it is helpful to give this option - especially for - those not familiar with how to execute an installation as an administrator and - those who don't know that LyX will install only the one or the other depending on how the installation is executed. Daniel
Re: Update on 2.3.0 situation and Windows-specific issues
On 15.03.2018 04:13, Scott Kostyshak wrote: On Wed, Mar 14, 2018 at 01:48:02AM +, Uwe Stöhr wrote: Why don't you add a sentence or two to the release notes for the experienced users that they can set in MiKTeX "never" to package updates. Experienced users will understand this. That is the most suitable solution. I think a dialog is more appropriate, because problems from upgrading MiKTeX could affect anyone, not just experienced users. I tend to agree. However, maybe the dialog should state only true things? So, either it should come up only when the 'never' option isn't set (preferably), or indicate that * MiKTeX will be updated (unless 'Install missing packages on-the-fly' is set to 'never') I know, that makes things worse in one respect (complicating the dialog)... Daniel
Re: Update on 2.3.0 situation and Windows-specific issues
I just tried the windows installer. Here is what it does (no evaluation intended since I probably don't understand enough of this). 1. LyX installs fine. 2. The user is not asked whether to update MiKTeX or cancel the setup. 3. There are a couple of messages that seem fine but are also a bit strange (see below). Daniel below Package "miktex-bin-2.9" is up to date. Sorry, but "MiKTeX Package Manager" did not succeed for the following reason: Package "miktex-console-bin-2.9" is already installed. The log file hopefully contains the information to get MiKTeX going again: C:/Users/Daniel/AppData/Local/MiKTeX/2.9/miktex/log/mpmcli.log You may want to visit the MiKTeX project page, if you need help. Sorry, but "MiKTeX Package Manager" did not succeed. The log file hopefully contains the information to get MiKTeX going again: C:/Users/Daniel/AppData/Local/MiKTeX/2.9/miktex/log/mpmcli.log You may want to visit the MiKTeX project page, if you need help. There are currently no updates available.
Re: Solution: Summary for the Win installer problem
On 05.03.2018 20:16, Uwe Stöhr wrote: Am 05.03.2018 um 19:37 schrieb racoon: However, it does not give the user a choice on whether to update MiKTeX or not. Yes, that is correct and I explained now in several mails why and that there is no other option. Sorry, I have a bit of a hard time following the discussion. Why is forcing the user to make a choice between going ahead with the setup and cancelling no option? Feel free to just ignore my question if you have answered that as well before. Also, I noticed that the MiKTeX Package Manager opens up for some reason and stays open. I am not sure why that is happening. This is another bug in MiKTeX I mentioned. There will therefore be a sentence I the announcement text. However, I just see that MiKTeX released a new installer as promised. This bug will then be fixed. Sorry, I must have missed that, too. Daniel
Re: Solution: Summary for the Win installer problem
On 05.03.2018 19:37, racoon wrote: On 04.03.2018 19:36, Uwe Stöhr wrote: Am 04.03.2018 um 16:19 schrieb Uwe Stöhr: Good news: There will be a new MiKTeX installer soon and the MiKTeX maintainer proposed a workaround for the main bug. I cannot promise that I will find time today to check if this will work for all cases. OK, I could check it and it works. The new installer can be found here: http://ftp.lyx.de/LyXWinInstaller/LyX2.3.0/ Now the users is not bothered at all. Everything that needs to be done is done by the installer silently. I would nevertheless wait with the announcement because the MiKTeX developer promised to make a release just for us soon. If it will be available by Tuesday, I will create a new installer, if not, let's release LyX 2.3.0 with the installer version 3 I linked above. Thanks Uwe. I have tried the installer. However, it does not give the user a choice on whether to update MiKTeX or not. One is only told that MiKTeX must be updated and can only click "OK". I guess it would be preferable to let the user choose to at least update or cancel the whole installation. But maybe that is hard to implement since the message comes up only after parts of LyX are already installed? But maybe one could inform the user at an earlier stage where she then has to click "Next" or so? Also, I noticed that the MiKTeX Package Manager opens up for some reason and stays open. I am not sure why that is happening. And the installation also worked without an active internet connection.
Re: Solution: Summary for the Win installer problem
On 04.03.2018 19:36, Uwe Stöhr wrote: Am 04.03.2018 um 16:19 schrieb Uwe Stöhr: Good news: There will be a new MiKTeX installer soon and the MiKTeX maintainer proposed a workaround for the main bug. I cannot promise that I will find time today to check if this will work for all cases. OK, I could check it and it works. The new installer can be found here: http://ftp.lyx.de/LyXWinInstaller/LyX2.3.0/ Now the users is not bothered at all. Everything that needs to be done is done by the installer silently. I would nevertheless wait with the announcement because the MiKTeX developer promised to make a release just for us soon. If it will be available by Tuesday, I will create a new installer, if not, let's release LyX 2.3.0 with the installer version 3 I linked above. Thanks Uwe. I have tried the installer. However, it does not give the user a choice on whether to update MiKTeX or not. One is only told that MiKTeX must be updated and can only click "OK". I guess it would be preferable to let the user choose to at least update or cancel the whole installation. But maybe that is hard to implement since the message comes up only after parts of LyX are already installed? But maybe one could inform the user at an earlier stage where she then has to click "Next" or so? Also, I noticed that the MiKTeX Package Manager opens up for some reason and stays open. I am not sure why that is happening. Daniel
Re: Summary for the Win installer problem
On 03.03.2018 18:17, Scott Kostyshak wrote: On Sat, Mar 03, 2018 at 12:26:35AM +, Uwe Stöhr wrote: Am 02.03.2018 um 20:59 schrieb Richard Heck: I don't know a lot about Windows, but let me just ask: Do we really want to force people to upgrade some other package when they install LyX? As I wrote in a previous post, the thing is that MiKTeX released in February a new package handling system. In order to be able to set up LyX the LyX installer needs to use this new system and therefore MiKTeX needs to be updated. I have a similar concern to Richard (and a similar disclaimer that I don't know much about Windows). Even if what you put is the case, I would prefer for the LyX installer to just give an error such as "Cannot install LyX without the newest version of MiKTeX. Please update your MiKTeX installation as follows: ..." But couldn't LyX ask the user to make a decision? Like "Cannot install LyX without the newest version of MiKTeX. Click Next to update MiKTeX or Cancel." Daniel
Re: Summary for the Win installer problem
On 02.03.2018 20:16, Uwe Stöhr wrote: Here is the final analysis: - I created a new installer that forces a silent MiKTeX update. This assures that every user gets the current MiKTeX package handling system. Do you know how I can check whether I already have the current MiKTeX package handling system (without actually updating)? Daniel
Re: Tar balls and binaries have been uploaded
On 02.03.2018 13:07, Uwe Stöhr wrote: Am 02.03.2018 um 08:14 schrieb racoon: I am quite sure that MiKTeX wasn't the problem in my case. Well, I worked a lot: Thanks a lot for your efforts. Scott, for the announcement I propose to write that users who have problems of getting the UserGuide compiled to a PDF should - uninstall LyX _and_ MiKTeX - install LyX 2.3.0 using the bundle installer that will automatically reinstall MiKTeX Since in my case an anti-virus software seemed to be the culprit, I suggest to add that - if one has a virus scanner installed and LyX cannot find "latex.exe", as a first step just close the installer and rerun it since this message appears even before LyX is installing this saves a lot of work and time compared to the alternatives. Daniel
Re: Tar balls and binaries have been uploaded
On 01.03.2018 19:31, Uwe Stöhr wrote: Am 28.02.2018 um 10:25 schrieb racoon: Strange. I just ran the installer again and now it works. Have you run MiKTeX update on every run of the installer as the installer suggested? If so your virus scanner is not to blame. I have not yet a solution for this other than to reinstall MiKTeX. That MiKTeX changed 3 weeks ago (therefore the RC2 installer has no issues) the packaging system one can describe the problem like this: The LyX installer uses a "key" for the "lock" of the package handling. Since the lock was replaced, the installer needs a new key. This key works for an updated MiKTeX but not for the old one. On top of this problem comes that one needs 2 runs of the MiKTeX update to get the new packaging system (lock). And even more there is a bug in the new packaging system of MiKTeX and the MiKTeX maintainer is currently away. The LyX installer has no chance to detect what MiKTeX packaging system is used on the PC. I think the only way is to build a special installer for LyX 2.3.0 that forces 2 update runs of MiKTeX. This will assure the success but annoys the user since maybe they already updated and 2 dry update runs can consume up to 4 minutes installation time in which nothing happens. I know how annoyed users are by every single button click they have to do unnecessarily. They will be confronted with 8 additional clicks because of the mentioned bug in MiKTeX. I think assuring a working installation is more important but if they refuse to do all the clicks I cannot force 2 update runs. Give me some time to think about this. I am quite sure that MiKTeX wasn't the problem in my case. In my first run of the installer I did not even get to the point where MiKTeX is searching for updates. And I just cancelled the installation before MiKTeX update was invoked. And I did not update MiKTeX between the first and second run and still, on the second, MiKTeX was found even before the updating by the installer. Daniel
Re: Tar balls and binaries have been uploaded
On 01.03.2018 18:50, Uwe Stöhr wrote: Am 01.03.2018 um 17:18 schrieb Scott Kostyshak: If this is the cause of all the problems, I guess all we can do is put a note in the announcement. I do not think we can officially recommend disabling anti-virus during the installation, but at least we can explain the situation. I am opposed to this. This is bad advertisement. We deliver a fully functional product. There will always be cases with problems restricted to software used by some persons. We should not announce this! I mean look in the forums of e.g. LibreOffice or InkScape for virus alarms, mangled registry settings and the like. Such cases will always happen. We are only responsible to things done by the product we deliver. I am not sure I understand why this is bad advertisement. Maybe you can explain this a bit more. I think, if the situation is explained that might be rather helpful. Otherwise we end up with some users being frustrated if they cannot install LyX. Worst case, they will not use LyX. And while true that forums of LibreOffice contain some discussion about false positives, they also clarify this on their pages: https://www.libreoffice.org/about-us/security/ Daniel
Re: Tar balls and binaries have been uploaded
On 28.02.2018 23:31, Scott Kostyshak wrote: On Wed, Feb 28, 2018 at 08:41:43PM +, racoon wrote: Yes, I can do it. But the earliest is tomorrow morning (so in about 10 hours). Just to be sure: The virus scanner did not detect anything. And I left the scanner activated during the second, successful installation process. It is just that the scanner did not do a deep scan the second time around probably because the scanner was already familiar with the file or so. Ah I see. I did not read carefully enough. In that case, since you already installed rc2, the scanner would also be familiar with it. So I no longer think it is worth the time to try to reproduce (unless someone else does) with rc2. It would be nice if we could find a way to reproduce with the 2.3.0 installer (so that we could perhaps find a solution). Do you know if the scanner keeps temporary files somewhere? Maybe if you restart your computer, the temporary directory will be cleared, and the scanner will re-scan if you install it again. Otherwise, is there a folder where Windows typically caches files? Is this something that the virus scanner might store in the registry? I would guess not, but I have no idea. So, I have checked but could not find a way to reproduce yet. However, I think I know what was going on. I was using Avast Antivirus and it has a feature called "CyberCapture". It is a bit explained here: https://support.avast.com/en-ww/article/Antivirus-CyberCapture-FAQ/ "CyberCapture is a feature in Avast Antivirus that detects and analyzes rare, suspicious files. If you attempt to run such a file, CyberCapture locks the file from your PC and sends it to the Avast Threat Lab where it is analyzed in a safe, virtual environment." It also states that "CyberCapture is able to handle large files, but it may take longer to deliver such files to the Avast Threat Lab." So, here is what I think happened. Avast did not recognize the large file and send it to its server which took quite a bit. I believe there was a colored frame with "Avast CyberCapture" around the installer while Avast still locked the installer but I kept going on with the installation which led to the installer not being able to communicate with my system and detect latex. I am not sure there is anything to be done about this on the LyX side. Apart from the privacy hazard this feature seems to be it is also strange that it still lets you use the program with limited functionality which leads to obvious problems for installers. I will disable this feature and see what will happen in the future. Daniel
Re: Tar balls and binaries have been uploaded
Or it might be even enough to just download a fresh file... I'll try in a bit. Daniel On 2018-02-28 23:31, Scott Kostyshak wrote: On Wed, Feb 28, 2018 at 08:41:43PM +, racoon wrote: Yes, I can do it. But the earliest is tomorrow morning (so in about 10 hours). Just to be sure: The virus scanner did not detect anything. And I left the scanner activated during the second, successful installation process. It is just that the scanner did not do a deep scan the second time around probably because the scanner was already familiar with the file or so. Ah I see. I did not read carefully enough. In that case, since you already installed rc2, the scanner would also be familiar with it. So I no longer think it is worth the time to try to reproduce (unless someone else does) with rc2. It would be nice if we could find a way to reproduce with the 2.3.0 installer (so that we could perhaps find a solution). Do you know if the scanner keeps temporary files somewhere? Maybe if you restart your computer, the temporary directory will be cleared, and the scanner will re-scan if you install it again. Otherwise, is there a folder where Windows typically caches files? Is this something that the virus scanner might store in the registry? I would guess not, but I have no idea. Thanks, Scott
Re: Tar balls and binaries have been uploaded
Yes, I can do it. But the earliest is tomorrow morning (so in about 10 hours). Just to be sure: The virus scanner did not detect anything. And I left the scanner activated during the second, successful installation process. It is just that the scanner did not do a deep scan the second time around probably because the scanner was already familiar with the file or so. Daniel On 2018-02-28 21:30, Scott Kostyshak wrote: On Wed, Feb 28, 2018 at 07:20:38PM +, racoon wrote: Uwe and racoon, do you recommend going forward with the release? Why was the above not a problem for rc2? My guess is that I did not have the virus scanner activated when installing rc2 but can't say for sure. We've decided to delay the release. racoon, I'm sorry to ask you to spend more time on this (especially now that you have things working and probably do not want to change anything), but would you be willing to uninstall 2.3.0 and see if you can reproduce the issue with the 2.3.0rc2 installer (e.g. having the virus scanner activated)? I'm curious in whether there is a difference between 2.3.0rc2 and 2.3.0. I do not blame you if you do not want to touch your working installation. You've already been so helpful in testing. Scott
Re: Tar balls and binaries have been uploaded
On 2018-02-28 17:50, Scott Kostyshak wrote: On Wed, Feb 28, 2018 at 11:36:33AM +, racoon wrote: On 28.02.2018 12:04, Uwe Stöhr wrote: Strange. I just ran the installer again and now it works. The installer checks the Windows registry to locate LaTeX program. If you have MiKTeX or TeXLive installed but the installer cannot find it, your virus scanner blocks that the installer have read access to the registry. This should not happen but virus scanners ate often over eager. Blocking read permission makes no sense in my opinion. In general I cannot recommend using virus scanners because the make make problems than they solve. I am not using such scanners for years now and I am virus-free nevertheless. The best way to stay safe us to use consequently only non-admin accounts. If you need to install things that should be available for all users of the PC, allow elevated rights only for the installer. Thus way virus programs cannot modify e.g. the registry. Only if there are bugs in Windows itself, this method can be unsafe but in this case also virus scanners don't help. Just my opinion. Thanks. I guess a blind spot is when an installer is actually infected with a virus and one gives the installer elevated right. That's where a virus scanner might be handy. Though most of the time I do not use one either. Uwe and racoon, do you recommend going forward with the release? Why was the above not a problem for rc2? My guess is that I did not have the virus scanner activated when installing rc2 but can't say for sure. Daniel
Re: Tar balls and binaries have been uploaded
On 2018-02-28 17:58, Scott Kostyshak wrote: On Wed, Feb 28, 2018 at 09:25:47AM +, racoon wrote: Strange. I just ran the installer again and now it works. To be clear, the installer works and after the installation you can successfully compile e.g. the user guide? That is correct. Daniel
Re: Tar balls and binaries have been uploaded
On 28.02.2018 12:04, Uwe Stöhr wrote: Strange. I just ran the installer again and now it works. The installer checks the Windows registry to locate LaTeX program. If you have MiKTeX or TeXLive installed but the installer cannot find it, your virus scanner blocks that the installer have read access to the registry. This should not happen but virus scanners ate often over eager. Blocking read permission makes no sense in my opinion. In general I cannot recommend using virus scanners because the make make problems than they solve. I am not using such scanners for years now and I am virus-free nevertheless. The best way to stay safe us to use consequently only non-admin accounts. If you need to install things that should be available for all users of the PC, allow elevated rights only for the installer. Thus way virus programs cannot modify e.g. the registry. Only if there are bugs in Windows itself, this method can be unsafe but in this case also virus scanners don't help. Just my opinion. Thanks. I guess a blind spot is when an installer is actually infected with a virus and one gives the installer elevated right. That's where a virus scanner might be handy. Though most of the time I do not use one either. Daniel
Re: Tar balls and binaries have been uploaded
On 28.02.2018 07:03, Scott Kostyshak wrote: On Tue, Feb 27, 2018 at 09:38:47PM +, Scott Kostyshak wrote: On Tue, Feb 27, 2018 at 08:24:43PM +, racoon wrote: Yes. What is the exact error message that is given and when is it given? Can you provide a screenshot? Also, have you uninstalled all previous 2.3.0 pre-release versions before trying to install 2.3.0 final? Strange. I just ran the installer again and now it works. I noticed that the virus scanner scanned the installer at the first run. Maybe that somehow interfered with the installer?!? Daniel
Re: Tar balls and binaries have been uploaded
On 28.02.2018 07:03, Scott Kostyshak wrote: On Tue, Feb 27, 2018 at 09:38:47PM +, Scott Kostyshak wrote: On Tue, Feb 27, 2018 at 08:24:43PM +, racoon wrote: Yes. What is the exact error message that is given and when is it given? Can you provide a screenshot? Screenshot attached. The installer cannot find my LaTeX distribution. Daniel
Re: Tar balls and binaries have been uploaded
Yes, uninstalled all 2.3.0 pre-release version before trying to install LyX. I think the dialog asks whether I want to use LaTeX and asks me to provide the location of latex.exe manually. I think I never saw that before. I'll look more closely at it and provide a screenshot in an hour or so when I am at my windows 7 computer. Daniel On 2018-02-28 07:03, Scott Kostyshak wrote: On Tue, Feb 27, 2018 at 09:38:47PM +, Scott Kostyshak wrote: On Tue, Feb 27, 2018 at 08:24:43PM +, racoon wrote: Yes. What is the exact error message that is given and when is it given? Can you provide a screenshot? Also, have you uninstalled all previous 2.3.0 pre-release versions before trying to install 2.3.0 final? Scott
Re: Tar balls and binaries have been uploaded
Yes. Daniel On 2018-02-27 18:07, Scott Kostyshak wrote: On Tue, Feb 27, 2018 at 05:08:23PM +, racoon wrote: I tried to install the windows binary but the installer does not find the latex.exe. So 2.3.0rc2 worked for you, but 2.3.0 does not? Scott
Re: Tar balls and binaries have been uploaded
I tried to install the windows binary but the installer does not find the latex.exe. Best, Daniel
Re: Extending layouts
On 24.01.2018 21:22, Richard Heck wrote: On 01/23/2018 03:49 AM, Jean-Marc Lasgouttes wrote: Now that I think about it, the advantage of using a special syntax is that there is not need to specify the file name, which makes the code safer. Idead of syntax: Input Input * InputParent I had a similar thought: something like class inheritance. The last of these looks best to me. And seems to get the job done I need at the moment. So, I'd be happy is something like this existed. Daniel
Re: Extending layouts
On 23.01.2018 11:50, Jean-Marc Lasgouttes wrote: When is it useful to extend an extension in the same user directory? I do not see the point... For example, you might have a module locally installed in the user dir which you want to extend. This is not strictly speaking an extension of an extension but maybe a good enough use case to consider it seriously? Daniel
Re: Extending layouts
On 23.01.2018 11:02, racoon wrote: On 23.01.2018 10:41, Jean-Marc Lasgouttes wrote: Le 23/01/2018 à 09:35, racoon a écrit : Yes, that would work for my case. However, it will fail if I want to extend an extension since it will not search my user directory. Let's say in the user directory there is 1. user_dir/foo.layout.ext which extends an extension Actually, what I proposed would be an alternative to the .ext proposal. It is not meant to be used at the same time. I see. Would your suggestion be able to allow the extension of extensions? If I see it correctly, my example could be changes as follows to extend your suggestion: 1. user_dir/foo.layout 2. user_dir/foo.ext 3. sys_dir/foo.layout 1 has a line line "Input bar.ext" and 2 has a line "Input foo.layout". The last line should of course be 1 has a line line "Input *foo*.ext" and 2 has a line "Input foo.layout". If "Input filename" not only searches in the higher order directory as I suggested before, this might work. (Notice that the 2's extension ".ext" is non-essential to the example.) Daniel
Re: Extending layouts
On 23.01.2018 10:41, Jean-Marc Lasgouttes wrote: Le 23/01/2018 à 09:35, racoon a écrit : Yes, that would work for my case. However, it will fail if I want to extend an extension since it will not search my user directory. Let's say in the user directory there is 1. user_dir/foo.layout.ext which extends an extension Actually, what I proposed would be an alternative to the .ext proposal. It is not meant to be used at the same time. I see. Would your suggestion be able to allow the extension of extensions? If I see it correctly, my example could be changes as follows to extend your suggestion: 1. user_dir/foo.layout 2. user_dir/foo.ext 3. sys_dir/foo.layout 1 has a line line "Input bar.ext" and 2 has a line "Input foo.layout". If "Input filename" not only searches in the higher order directory as I suggested before, this might work. (Notice that the 2's extension ".ext" is non-essential to the example.) Daniel
Re: Extending layouts
On 23.01.2018 07:11, Richard Heck wrote: On 01/22/2018 04:23 AM, Jean-Marc Lasgouttes wrote: Le 22/01/2018 à 10:10, racoon a écrit : So LyX should load the library's stdinset.inc first and then load the code that extends it next. Richard, who ran into similar problems as I did, suggested that LyX could be enhanced by automatically looking for and loading an .ext file, e.g. stdinset.inc.ext. I think that is a good idea and this concept could be used for other sorts of layout files, like .modules. One idea that I do not like about the .ext file idea is that it does not scale when you want to extend a file that has already been extended, which might happen if we had a site directory as proposed in http://www.lyx.org/trac/ticket/10326. One idea I had about that is to change the behavior of Input (which searches for files in user dir, then build dir, and finally system dir) so that it skips to the next level when doing recursive input. Example: * In user_dir/foo.layout, if I do "Input foo.layout", it will search in build dir, and then system dir * in build_dir/foo.layout, it will try only sys_dir/foo.layout The same will work if we add a site directory. Would that fix your issue, or are there cases where it would not do what you expect? My sense, from our previous discussion, is that this would work in the cases racoon had in mind. But I'm not sure why this wouldn't scale. We could of course look also for *.ext.ext. These ideas could also probably be combined. I guess a benefit of Jean-Marc's suggestion is that it provides the user with more freedom to choose filenames (if his suggestion is extended in some way like I proposed in reply to him). Daniel
Re: Extending layouts
On 22.01.2018 11:23, Jean-Marc Lasgouttes wrote: Le 22/01/2018 à 10:10, racoon a écrit : So LyX should load the library's stdinset.inc first and then load the code that extends it next. Richard, who ran into similar problems as I did, suggested that LyX could be enhanced by automatically looking for and loading an .ext file, e.g. stdinset.inc.ext. I think that is a good idea and this concept could be used for other sorts of layout files, like .modules. One idea that I do not like about the .ext file idea is that it does not scale when you want to extend a file that has already been extended, which might happen if we had a site directory as proposed in http://www.lyx.org/trac/ticket/10326. One idea I had about that is to change the behavior of Input (which searches for files in user dir, then build dir, and finally system dir) so that it skips to the next level when doing recursive input. Example: * In user_dir/foo.layout, if I do "Input foo.layout", it will search in build dir, and then system dir * in build_dir/foo.layout, it will try only sys_dir/foo.layout The same will work if we add a site directory. Would that fix your issue, or are there cases where it would not do what you expect? Yes, that would work for my case. However, it will fail if I want to extend an extension since it will not search my user directory. Let's say in the user directory there is 1. user_dir/foo.layout.ext which extends an extension 2. user_dir/foo.layout of 3. sys_dir/foo.layout Since Input foo.layout will search only in the higher order directories, sys_dir and build_dir, there is no way to reach 2 from 1. A way around would be to start search the user directory (but, obviously, only if the filename differs from itself) and then upwards. Daniel
Extending layouts
I am bringing over a topic from the general list for dev discussion: By default LyX loads standard layouts and insets. Is there a way to extend them without overwriting the default .inc file and without using a module? Let's say I want to extend the standard Note style. I don't want to use a module since I want to make a non-optional change to the Note inset. For example, I want to use another font size for all LyX notes. If I understood correctly, I can just put a copy of the stdinset.inc file from the library to the user directory. But this will have the unwelcome effect to overwrite whatever is in the stdinset.inc in the library directory. So, to avoid unwanted consequences, I will have to update my user stdinset.inc every time the library stdinset.inc changes, for example, in a new version of LyX. So I would rather like to *extend* the current library file by just the font-size changes by InsetLayout Note:Note CopyStyle Note Font Size Small EndFont End So LyX should load the library's stdinset.inc first and then load the code that extends it next. Richard, who ran into similar problems as I did, suggested that LyX could be enhanced by automatically looking for and loading an .ext file, e.g. stdinset.inc.ext. I think that is a good idea and this concept could be used for other sorts of layout files, like .modules. Daniel
AddToToc does not work as expected
Hi, I boldly tried to add all enumerated items to the outliner by adding the following to the Local Layout: OutlinerName enum "Enumerates" Style Enumerate CopyStyle Enumerate AddToToc enum IsTocCaption true End Unfortunately, it seems not to work. And I am wondering whether this is as intended or not. First, when adding different items to a list, like 1. One 2. Two 3. Three They do not get separated in the toc. The output will be one item that reads 1. One 2. Two 3. Three Second, the toc item gets updated only after a new item or paragraph is started after it. So if one only writes Test 1. One and then does not add another paragraph after it but sets the cursor only back to the first "Test" line, then no item is generated. Daniel
Discussion for ticket #10975
Hi! Richard suggested to get some comments on enhancement request #10975. http://www.lyx.org/trac/ticket/10975 When working with cross references one often uses the same format. The Cross-reference dialog already takes this into account by suggesting the last used format by default. The same would be helpful when using Copy as Reference from a label context menu. Daniel
Re: Slow opening of Document Settings in RC1
On 02.11.2017 19:15, Jürgen Spitzmüller wrote: Am Donnerstag, den 02.11.2017, 18:41 +0200 schrieb racoon: On 02.11.2017 19:22, Jürgen Spitzmüller wrote: Am Donnerstag, den 02.11.2017, 17:21 +0200 schrieb racoon: The opening of Document Settings takes about 8 seconds for some Documents on my system. LyX becomes unresponsive in the meanwhile. (Core 2 Duo, Win7) I noticed that the delay became longer in beta1. But it was much faster still. Do you have local layout setting in these documents? If so, does the speed improve if you convert these to the current format (via the "Convert" button)? No local layout present. Could you provide us with such a document? Not at the moment. But I'll look into that. Daniel Jürgen
Re: Slow opening of Document Settings in RC1
On 02.11.2017 21:34, Andrew Parsloe wrote: On 3/11/2017 5:44 a.m., racoon wrote: On 02.11.2017 17:21, racoon wrote: The opening of Document Settings takes about 8 seconds for some Documents on my system. LyX becomes unresponsive in the meanwhile. (Core 2 Duo, Win7) I noticed that the delay became longer in beta1. But it was much faster still. Seems like these delays change. After a fresh start of LyX it takes about 8 seconds. But sometimes this gets quicker when LyX has been in use for a while. Daniel I can't reproduce. I'm running rc1 (Uwe's installer), Windows 7, standard 'High Street' laptop from about 4 years ago. I start LyX, open a document, access Document Settings and it shows in a second or less. Did you see the "for some documents" part? It is definitely quicker for new files (just a bit over a second). I haven't figured out what it correlates with. For example, the User Manual seems fine. Daniel Andrew PS Following this thread results in weird timings on my computer. racoon 4:21 a.m. racoon 5:40 a.m. (reply to Scott 6:02) racoon 5:41 a.m. (reply to Juergen 6:22) racoon 5:44 a.m. Scott 6:02 a.m. Juergen 6:22 a.m. Juergen 7:15 a.m. Could be that my computer was on the wrong settings after switching time zones... I once spent some weeks inadvertently using US Pacific time but I've checked and it is correctly set for New Zealand. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Slow opening of Document Settings in RC1
On 02.11.2017 19:22, Jürgen Spitzmüller wrote: Am Donnerstag, den 02.11.2017, 17:21 +0200 schrieb racoon: The opening of Document Settings takes about 8 seconds for some Documents on my system. LyX becomes unresponsive in the meanwhile. (Core 2 Duo, Win7) I noticed that the delay became longer in beta1. But it was much faster still. Do you have local layout setting in these documents? If so, does the speed improve if you convert these to the current format (via the "Convert" button)? No local layout present. Daniel Jürgen Daniel
Re: Slow opening of Document Settings in RC1
On 02.11.2017 17:21, racoon wrote: The opening of Document Settings takes about 8 seconds for some Documents on my system. LyX becomes unresponsive in the meanwhile. (Core 2 Duo, Win7) I noticed that the delay became longer in beta1. But it was much faster still. Seems like these delays change. After a fresh start of LyX it takes about 8 seconds. But sometimes this gets quicker when LyX has been in use for a while. Daniel
Re: Slow opening of Document Settings in RC1
On 02.11.2017 19:02, Scott Kostyshak wrote: On Thu, Nov 02, 2017 at 03:21:02PM +, racoon wrote: The opening of Document Settings takes about 8 seconds for some Documents on my system. LyX becomes unresponsive in the meanwhile. (Core 2 Duo, Win7) I noticed that the delay became longer in beta1. But it was much faster still. Can you give an approximate guess on how long it was in each version? 2.3.0rc1: 8 seconds 2.3.0beta1 about how long?? 2.3.0alpha1 about how long? In 2.2.3 about how long? For sure I did not notice such a long delay before. My guess is about 2-4 seconds. With LyX 2.2.3 at the lower and beta 1at the upper boundary. I don't know about alpha1. Daniel I thought Uwe had reported something like this particularly for document settings, but I could not find the trac ticket. Thanks, Scott
Re: Beta1 is slow on undo
On 07.10.2017 19:09, racoon wrote: Hi, I noticed that beta1 shows some slowness when undoing with some of my documents. While undoing is instantaneous in 2.2.3, 2.3 takes about a second to respond to it. Did anyone notice this? I don't have a very fast computer though. In RC1 the undo speed is back to normal, i.e. barely noticeable delay. Thanks! Daniel Best, Daniel
Re: Color reset in 2.3.0rc1
On 02.11.2017 17:30, Jürgen Spitzmüller wrote: Am Donnerstag, den 02.11.2017, 13:55 +0200 schrieb racoon: It seems that rc1 resets a couple of colors for some reason. The reason is the renaming of the colors collapsable and collapsableframe to collapsible and collapsibleframe, respectively. We forgot to increase the prefs format. Fixed now in master. We should backport this to 2.3.x as well, Scott. The other I noticed was the frame of insets. Unfortunately, none of the colors in Preferences seems to change that frame color back. Was the possibility of a customization of the frame abandoned? collapsibleframe should work. Thanks. I can verify that using collapsibleframe in the preferences file works. Jürgen Daniel
Slow opening of Document Settings in RC1
The opening of Document Settings takes about 8 seconds for some Documents on my system. LyX becomes unresponsive in the meanwhile. (Core 2 Duo, Win7) I noticed that the delay became longer in beta1. But it was much faster still. Daniel
Color reset in 2.3.0rc1
It seems that rc1 resets a couple of colors for some reason. (I don't know about beta1 since I started with fresh settings with that version.) One was collapsable, aka "collapsible inset text". The other I noticed was the frame of insets. Unfortunately, none of the colors in Preferences seems to change that frame color back. Was the possibility of a customization of the frame abandoned? Daniel
Re: Show changes don't work with URL (and maybe other insets)
On 20.10.2017 09:46, racoon wrote: Open and typeset the attached file with a deleted URL and active show changes. It shows both the actual and expected result. Notes: While the current algorithm seems fine for some insets, like footnotes, it falters at other insets, like URL, which do not interpret its content as LaTeX code. Okay, it seems pretty impossible to solve this. The problem is that when only plain text is allowed in an inset, like URL, changes can be marked as on whole inset but not different changes within it. However, here is what one might reasonably do: if the content is only plain, i.e. forceplain is true, to not end the \lyxadded and \lyxdeleted before it but just wrap it around the inset. and additionally, but I guess this is not such a simple change, have an inset setting that disables change tracking within it, so that there will be no \lyxadded and \lyxdeleted within the inset. Daniel
Re: List of notes not in beta1
On 21.10.2017 11:31, Jürgen Spitzmüller wrote: Am Samstag, den 21.10.2017, 11:12 +0300 schrieb racoon: On 21.10.2017 10:28, Jean-Marc Lasgouttes wrote: Le 20 octobre 2017 23:37:53 GMT+02:00, racoon <xraco...@gmx.de> a écrit : Thanks. Well, I guess there must be something wrong with my configuration then... Did you customize your layout file(s) related to notes? Thanks. Yes, I did. And now that I removed the layout file it works. However, the exact same layout file works in LyX 2.2. Now I have to figure out what's going on. You probably miss these two lines in your own definition of notes: AddToToc note IsTocCaption true Great, that does the trick. I haven't looked at the AddToToc and IsTocCaption yet. Sounds good. Daniel Jürgen Daniel
Re: List of notes not in beta1
On 21.10.2017 10:28, Jean-Marc Lasgouttes wrote: Le 20 octobre 2017 23:37:53 GMT+02:00, racoon <xraco...@gmx.de> a écrit : Thanks. Well, I guess there must be something wrong with my configuration then... Did you customize your layout file(s) related to notes? Thanks. Yes, I did. And now that I removed the layout file it works. However, the exact same layout file works in LyX 2.2. Now I have to figure out what's going on. Daniel
Re: Windows: bring window to front
On 17.10.2017 14:07, Enrico Forestieri wrote: On Tue, Oct 17, 2017 at 11:50:23AM +0300, racoon wrote: On 17.10.2017 06:42, Scott Kostyshak wrote: On Mon, Oct 16, 2017 at 01:09:34PM +, racoon wrote: Hi, Is the patch for http://www.lyx.org/trac/ticket/10469 already in beta1? If so, it seems not to work. If not, maybe it can make it to rc1? The patch is in beta1. If the feature doesn't work, then that means the fix didn't work for you. Yes, when opening LyX files from the explorer, LyX still does not come to the top. Strange, I thought I tested the patch before and it worked. But I probably did not try it from the explorer but rather from the command line. I am not sure there is a difference wrt the problem. It works for me. Make sure that you have "Single Instance" checked and "LyXServer pipe" defined in the preferences. I have it checked and defined, respectively. (Though I am wondering why "Single instance" should make a difference at all and "LyXServer pipe" at least for opening documents from the explorer.) But it doesn't work. Just to be sure, you tested on Windows beta1, right? Daniel
Re: List of notes not in beta1
On 20.10.2017 23:20, Andrew Parsloe wrote: On 20/10/2017 6:50 p.m., racoon wrote: On 19.10.2017 15:25, Kornel Benko wrote: Am Donnerstag, 19. Oktober 2017 um 14:00:27, schrieb racoon <xraco...@gmx.de> My documents do not show the "Notes" list in the Outline pane in beta1. Is that a bug? Daniel Insert a note first? Kornel Yes, I have plenty of them. Does your question suggest that it works for you? Daniel I'm using beta1 on windows7. The current document includes notes and there *is* a Notes option in the Outliner. (I need to use the slider to bring it into view.) When I choose it, a list of notes is presented. Andrew Thanks. Well, I guess there must be something wrong with my configuration then... Daniel
Re: List of notes not in beta1
On 20.10.2017 17:06, Kornel Benko wrote: Am Freitag, 20. Oktober 2017 um 16:39:01, schrieb racoon <xraco...@gmx.de> On 20.10.2017 12:20, Kornel Benko wrote: Am Freitag, 20. Oktober 2017 um 08:50:57, schrieb racoon <xraco...@gmx.de> On 19.10.2017 15:25, Kornel Benko wrote: Am Donnerstag, 19. Oktober 2017 um 14:00:27, schrieb racoon <xraco...@gmx.de> My documents do not show the "Notes" list in the Outline pane in beta1. Is that a bug? Daniel Insert a note first? Kornel Yes, I have plenty of them. Does your question suggest that it works for you? Daniel Yes, I tried with every note type. Kornel That is strange then. Daniel What about MWE? Kornel Attached. Also a screenshot of what I (not) see. Maybe I messed up my UI with some customizations? Is there a way to edit the lists that show up? Daniel a_note.lyx Description: application/lyx
Re: Ticket #3072: incomplete booktabs support: optional arguments of \cmidrule not supported
On 20.10.2017 23:56, Scott Kostyshak wrote: Please make sure to add your thoughts to the ticket, so they don't get lost. Done. http://www.lyx.org/trac/ticket/3072#comment:11 Daniel
Re: List of notes not in beta1
On 20.10.2017 12:20, Kornel Benko wrote: Am Freitag, 20. Oktober 2017 um 08:50:57, schrieb racoon <xraco...@gmx.de> On 19.10.2017 15:25, Kornel Benko wrote: Am Donnerstag, 19. Oktober 2017 um 14:00:27, schrieb racoon <xraco...@gmx.de> My documents do not show the "Notes" list in the Outline pane in beta1. Is that a bug? Daniel Insert a note first? Kornel Yes, I have plenty of them. Does your question suggest that it works for you? Daniel Yes, I tried with every note type. Kornel That is strange then. Daniel
Re: Ticket #3072: incomplete booktabs support: optional arguments of \cmidrule not supported
On 20.10.2017 11:06, racoon wrote:
For example, if a column with a \cmidrule underneath is set to "align
center" then this should be inherited by its \cmidrule, i.e.
\cmidrule(c){...}
Or maybe if all columns just below a \cmidrule are set to "align
center"? In this way it is still possible to use some other custom
distribution of columns.
Daniel
Ticket #3072: incomplete booktabs support: optional arguments of \cmidrule not supported
Maybe some arguments of \cmidrule could be set automatically without
additional UI?
For example, if a column with a \cmidrule underneath is set to "align
center" then this should be inherited by its \cmidrule, i.e.
\cmidrule(c){...}
Also, a \cmidrule should never stretch over more than one (multi)column.
This makes possible to to have rules with small breaks in between.
See both cases here in action here:
https://tex.stackexchange.com/a/60604/36836
I know that this might not be the wanted result in all cases. But maybe
it is what is wanted in almost all cases. And once a UI gets implemented
to set these optional arguments, in the Border dialog or so, then this
could override the default as outlined above.
Daniel
Show changes don't work properly with display math
Open and typeset the attached file with a deleted text immediately followed by a display math (the way one should typeset display math without extra space in LyX) and active show changes. It shows both the original results without deletions and the actual results. Notes: The main problem is shown at 2 compared to 1 where the display math is translated to the top. But there is also a minor problem. When preceded by a new paragraph, as shown in 3 and 4, the display math is translated to the right and bottom which does not seem fully correct either. (The result is independent of the enumerations.) Daniel show_changes_display_math.lyx Description: application/lyx
