search

Zettlr / Zettlr

Your One-Stop Publication Workbench
https://www.zettlr.com
GNU General Public License v3.0
10.35k stars 637 forks source link

1.4.0-beta: a big THANK YOU and some issues #263

Closed samarulmeu closed 5 years ago

samarulmeu commented 5 years ago

First of all a big THANK YOU for the great work. I tested it during the weekend before posting anything. The app is amazingly fast now and I think that #253 is solved. The new Karl-Marx-Stadt theme is very nice.

Now, the bad stuff:

Later edit: I forgot to thank you for matching the Quicklook with the Custom CSS.

nathanlesage commented 5 years ago

After reinstall the Zettlr did not recognize my config file and did not open the old directories.

That is not good. Any idea why? Did it omit all other preferences as well, or did it only forget the directories? The first one could be easily explained by errors in the boot process (b/c if there's something bad happening, config won't load the file at all and it seems as if it removed the config), while I have no idea of why the latter may be.

A moody behavior of the file explorer. Sometimes it forgets the opened directories. And I just have to copy again the old config.json. This I am still investigating.

Ugh … please share any insights you find! :)

If the USB stick is unmounted when Zettlr is still opened the notes are still listed

Should not prove too difficult, this is something I forgot/didn't think of!

[...] but when I restarted Zettlr the file was not shown in the directory (although it still was there) -- this was happening in 1.3.0. I had to close and open the containing directory in order that Zettlr sees it again [...]

What the heck -- I will look into that as well.

It seems that the autosaving is not happening so often as in the older versions?

It may very well be that I just accidentally deleted the final check for modifications to save a file during my refactoring ... I'll investigate! Until then: Save early, save often ... I knew it'd be a good idea to leave the Save-option available even though autosave should have you covered, hehe 😝

Inconsistency in the search related to theme colors: using the Karl-Marx-Stadt you get what you can see in the picture.

You mean that search results are displayed using green, while the theme is in red? Well, after your brilliant idea to move the colours to CSS variables, it shouldn't prove to difficult to adapt the colours (for all themes, for that matter)!

As a personal preference, I liked more the old switches as you can see below.

I knew something like this would occur =D The new drop-shadow-toggles are in fact a result from me testing out bear, when I was writing the KMS-Theme. I thought it'd be a nice addition, because I'm the type who always needs to see something new; if the visuals stay the same for too long I get the impression as if nothing has changed, but this is only my personal preference!

nathanlesage commented 5 years ago

Oh and btw: concerning issue #253 ... I didn't even apply the fix I mentioned, so this shouldn't have been affected at all 😄

samarulmeu commented 5 years ago

Some updates:

After reinstall the Zettlr did not recognize my config file and did not open the old directories.

It seems that I had to wait longer. At work after upgrading Zettlr and not closing it too soon it finally opened all my directories.

Oh and btw: concerning issue #253 ... I didn't even apply the fix I mentioned, so this shouldn't have been affected at all smile.

Then it had something to do with file management. I can't believe how responsible is Zettlr now with the same kind of files.

You mean that search results are displayed using green, while the theme is in red? Well, after your brilliant idea to move the colours to CSS variables, it shouldn't prove to difficult to adapt the colours (for all themes, for that matter)!

Yes. As this cannot be done through Custom CSS or, at least, I couldn't.

nathanlesage commented 5 years ago

It seems that I had to wait longer. At work after upgrading Zettlr and not closing it too soon it finally opened all my directories.

Hah, so the core rewrite indeed had the intended results :) The app is no longer blocked, but of course reading in the files will take approx. the same amount of time! That's wonderful to hear!

Yes. As this cannot be done through Custom CSS or, at least, I couldn't.

Yup, it's currently still being done in the core framework, but should pose no problem to move that behaviour to use a root variable as well! 🎉

samarulmeu commented 5 years ago

Although this issue appears also on previous versions I thought I shouldn't start a new bug report.

So, when you have a link inside parentheses Zettlr does not render it the way it should, it also hide the final one.

links

And I think that #253 should still be investigated. Sometimes I again get lag when working with files with a lot of links in them.

samarulmeu commented 5 years ago

How often does Writing Target indicator should update?

After setting the writing target (I already had ~ 350 words) at 1000 words and writing more than 130 words the indicator remained unchanged. I opened other notes, saved again and again, wrote more words, but nothing helped. Only restarting Zettlr made a difference.

nathanlesage commented 5 years ago

So the writing target indicator does not update properly? This sounds to me like a new issue! :)

nathanlesage commented 5 years ago

Oh and concerning the links: Your screenshot exemplifies why the link rendering is currently laggy: It checks whether or not the found link is within a comment section, and if it is, it does not attempt to render. The check for that is rather hard. And concerning the last brace: This is something I've been annoyed myself, but I didn't really figure out the regex necessary to avoid that ...

samarulmeu commented 5 years ago

Oh and concerning the links: Your screenshot exemplifies why the link rendering is currently laggy: It checks whether or not the found link is within a comment section, and if it is, it does not attempt to render. The check for that is rather hard.

The screenshot was for the last parenthesis issue. There is no lag in this case (2 links in a file), only in the cases explained in the #253 with a lot of links. But this I'm still investigating.

And concerning the last brace: This is something I've been annoyed myself, but I didn't really figure out the regex necessary to avoid that ...

Can you pin point in the code the regex? Maybe I'll give it a try...

nathanlesage commented 5 years ago

The screenshot was for the last parenthesis issue.

Ah alright. Concerning the investigation: How about you send me one of the affected files via Mail or so that I can have a closer look at the performance profile of the function calls to identify the issue? That would be great!

And concerning the regex, please don't be shocked:

https://github.com/Zettlr/Zettlr/blob/bbe434c0bc75bc9a5c430885789b76ffb7fbda51/source/renderer/assets/codemirror/zettlr-plugin-render-links.js#L22

Most of it is simply the copied regular expression from the Markdown mode, what's the interesting part is the first one: \[([^\]]+)\]\(([^\s]+)\) Something there's off. If you add the closing brace to the inner capturing group ([^\s)]) Wikipedia-style links that contain braces won't work. If you leave it out, it'll capture all trailing braces :/

samarulmeu commented 5 years ago

Ah alright. Concerning the investigation: How about you send me one of the affected files via Mail or so that I can have a closer look at the performance profile of the function calls to identify the issue? That would be great!

This could be an example. A saved file from web that I converted to Markdown using pandoc. Now, the response time is considerably improved from the 1.3.0 version, but the app still hangs if I have more file opened and I just browse around and I have the Render Links enabled.

usedToBeHuman.md.zip

Most of it is simply the copied regular expression from the Markdown mode, what's the interesting part is the first one: \[([^\]]+)\]\(([^\s]+)\) Something there's off. If you add the closing brace to the inner capturing group ([^\s)]) Wikipedia-style links that contain braces won't work. If you leave it out, it'll capture all trailing braces :/

Can you just check if you have )) followed by a space (which will not happen inside a URL) and then, when you render the link you just add a final parenthesis?

nathanlesage commented 5 years ago

Thank you for the file! I just ran a performance profiler and as we all suspected: It's the token-checker that takes so much time:

image

I'll run some tests, because I may know of a way to remedy this without having to remove that functionality and improve performance :)

Concerning the regex: One thing that'd be possible would be to check for multiple closing braces at the end of a link. This may break some links, but I think there are just not that many URLs with two or more closing braces at their end!

So in case we have a link like [Hello](example.com/abcd)), I'll just back up one character so that the final closing brace is not included in the rendered link!

samarulmeu commented 5 years ago

Thank you again.

And about the links -- you are right. I don't think they'll be so many broken ones, considering that there are more cases in which a link is inside parentheses.

nathanlesage commented 5 years ago

Sooo, the link rendering modification went smoothly, it's now MUCH faster! So one thing is out of the way now :)

nathanlesage commented 5 years ago

And here's to the Markdown links within braces!

nathanlesage commented 5 years ago

The root var idea was indeed great, now the coloured heatmap uses the corresponding theme's main colour hue:

image

samarulmeu commented 5 years ago

Nicely done. And now I'll be able to specify the root color in the Custom CSS?

And please don't forget about the file duplicate option.

Hope I'm not asking too much.

I'm still amazed by the great work you're doing.

nathanlesage commented 5 years ago

Nicely done. And now I'll be able to specify the root color in the Custom CSS?

Yep, just throw in some

:root {
  --some-var: some-value;
}

To see all available root vars, simply have a look in the dev consoles -> elements -> at the very bottom of the bottom list there's the :root-element!

samarulmeu commented 5 years ago

So simple. I don't know how I omitted this. Thanks! After the next beta I'll have to simplify my Custom CSS. It's so bloated right now. And most of it is already solved by the new Karl-Marx Stadt theme. :)

nathanlesage commented 5 years ago

So I guess you like red? :D

samarulmeu commented 5 years ago

In this case, yes! White, black and red -- a perfect combination for an editor.

nathanlesage commented 5 years ago

Interesting! Glad you like it :)

samarulmeu commented 5 years ago

So, another issue I encountered by chance (unmounting a USB drive got me a Javascript error window from Zettlr that was supposetly closed): after I close it there are still processes hanging. I tried more than once and zettlr is still there after closing it.

nathanlesage commented 5 years ago

Yup, there have been some instances of zombie-processes; I've encountered them myself. In this case, at least a new window will be opened so that you can quit the process again. Doesn't this work on your machine?

samarulmeu commented 5 years ago

On Linux there's no window opened. That is why I said I encountered the problem by accident. Only ps aux revealed the zettlr processes hanging.

nathanlesage commented 5 years ago

Oh, alright. how often does this happen?

samarulmeu commented 5 years ago

I think that it always does. For example, today I used Zettlr in the morning and close it around noon and an hour later it was still there.

This is how the processes hanging look like...

processes

nathanlesage commented 5 years ago

Did you close Zettlr using Ctrl+Q or just closed the window …?

samarulmeu commented 5 years ago

Just closed the window.

nathanlesage commented 5 years ago

Alright, sounds like an issue with the event emitter that is supposed to emit an "all-windows-closed" event to the browser window, which doesn't seem to be emitted on your system — I've had this problem on Windows as well and I don't know why it happens :/

samarulmeu commented 5 years ago

So, after some tests: Ctrl+Q immediately closes all processes but closing the window displays the behavior I've mentioned (processes hanging in the background).

nathanlesage commented 5 years ago

Thanks! I'll see what I can do :)

samarulmeu commented 5 years ago

I know that you are in the process of rewriting the sidebar and maybe this issue is already solved, but it will be nice if the app will remember the size of the sidebar between restarts and not always return to the default.

nathanlesage commented 5 years ago

Nope, it doesn't save the sidebar sizes currently, and I wouldn't want to do that right now because the app would need to check for: window sizes (if you had Zettlr open on a big external monitor and then open it on your Laptop screen), screen sizes and making sure it's correctly applied :/ But maybe I can crunch it into 1.4 after some more betas?

samarulmeu commented 5 years ago

Closed as most of the issues are solved and the one left (hanging processes) is moved to #290