-
-
Notifications
You must be signed in to change notification settings - Fork 612
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ENHANCEMENT] Always use forward slashes on Windows #732
Comments
That is some bug, I suspect, but it's one of the mosquito type, hence difficult to spot. But the idea to simply enforce forward slashes is in fact reasonable! |
I left a comment on issue #543 about the Windows + absolute path + export mess ;) |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This issue has been automatically closed due to inactivity. If you believe that this issue is relevant for many users and should not be closed, feel free to comment so that the admins will be notified. |
The main point kind of got lost in the export issues, but I still think that for standardisation & interoperability, enforcing forward slashes would be a good move. I can test exports on Windows if it's of any help. But so far I haven't encountered any issues manually using forward slashes in image paths :) |
Yeah, I think so, but I'm always a little bit afraid of what happens if we just set forward-slashes in every case on Windows :S Unfortunately I don't have the time to investigate, so let's first see what the other issue does, and if the problems still persist, then f*** it and we have to go the additional mile |
If you have any indication of where in the code the path formating/normalisation happens, I can have a look and test (although JS is not my forte). I totally understand your concerns though ;) |
See: https://nodejs.org/api/path.html The problem is we make use of this function, and changing it in a fair amount of places is simply not feasible … |
I gave it a try, together with my other suggestion to only use the filename+extension as the caption ;) But I'm kinda hesitant to make a pull request on this because, as I mention in the commit comment, it should ideally be up to the user to choose whether they want this or not. |
Looks definitely cleaner than my old code =D I don't know, are only images affected by this? |
Yes that's only for images during a drag&drop or paste. (I don't know what else is created automatically with paths... dragging a .md file create an internal link [[id]], no slashes... pasting an internet links keeps the forward slashes... am I missing something?) I guess if the change is applied like this, becoming the new default, some Windows users might have files mixing both old-style absolute paths + backslashes AND new, always-relative POSIX paths. I don't know. It might bother some people? They can still change it manually after an imagine insertion, though ;) |
Mh … I am still at a loss why ONLY this doesn't work o_O So … do the previews work? Or is it only the Pandoc exporting? Because if the latter, then I could message tarleb and ask him about this, maybe it's a bug …? |
Ooops, hold on, maybe there's a misunderstanding here! I thought "I don't know, are only images affected by this?" was for my suggested changes (I since made a PR of it). Actually both previews & export work, and the only thing that is still not working in the current develop branch is this : #543 (comment) = backslashes in image captions are sometimes misunderstood as "control sequence" for Pandoc. A nice side effect of my proposal is that, since it's using only the basename in the image caption, there are no more slashes in it ;) If you want to be extra cautious, you probably need to write a nice regex that escape all backslashes in images captions before sending everything to Pandoc? |
Aaah, I see!
If only the image captions produce errors, then I'd rather suggest something different: Keep all the paths the way they are BUT only implement a regex that escapes all backslashes (+ obviously only use the basename, I don't know why I didn't do that before) |
@nathanlesage Apologies for necromancy on this closed issue. |
@nathanlesage Is it intentional to not provide forward slashes in url in windows when drag-and-drop images? |
First of all, thanks for your nice work on Zettlr!
On Windows, when images are added through drag&drop or copy-paste, Zettlr uses backslashes as a path delimiter. This is the default on Windows, but these paths don't work on other systems, or on Github.
Proposed Changes
Since Zettlr seems to be able to display images when their path uses forward slashes, even on Windows, why not enforce forward slashes for all image paths on Windows?
(an HTML editor wouldn't use backslashes for its paths, would it?)
Caveats
It might break some exports; some export processes might need to convert forward slashes back to backslashes to be able to load images properly.
(I only tested ODT export so far: relative paths work with either forward or backslashes. Absolute paths never seem to work so that doesn't change much)
The text was updated successfully, but these errors were encountered: