add flag to specify which line feed to use #3567
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
... for downloadable code blocks. This is more a feature request than it is a pull request, but I've done it like this to easily show/allow others to modify the code. Underneath my changes, at line 34, I've put in a commented out alternative version, primarily to demonstrate an alternative approach. I've been using Dokuwiki for a while to create and provide scripts for novice users to download and use for a small custom distribution based on Linux we are building that is typically deployed and edited on a remote network connection, using another computer to make those edits. This all works wonderfully well when downloading the files in a strictly Linux environment, however I've found out that users of Windows computers (which I've found out, is most of my reader's primary OS) were receiving these files with the incorrect CRLF line terminators. Looking through the web I found dokuwiki#863 , a change made around six years ago making DokuWiki automatically detect and change the line feed used in the downloaded file depending on the user's operating system. The actual commit merged that fixed it is dokuwiki#872 . This is a neat feature, and I wouldn't want to undo that behaviour by default, but I would like to add a flag that editors can use to specify "hey, this is a Unix script, and the linefeeds need to remain untouched", so that neophyte users can simply download and use the script files as they are without having to do additional line feed conversions. I'm aware that I'm changing the number of arguments that this function accepts, and that this would cause issues elsewhere, that's precisely why I'm asking for assistance here! I'm not a veteran DokuWiki coder, so please feel free to completely change this code, or close this pull request if it can be implemented in a much better way. The original PR I'm seeing that changed this behaviour in the first place only edited this file, so I'm not even sure where to begin looking for other files that might be calling this one, if there are any at all.
|
Is there overlap with this and the highlighting options: https://www.dokuwiki.org/syntax_highlighting |
Klap-in
reviewed
Dec 21, 2021
| @@ -25,10 +25,16 @@ public function code($text, $language = null, $filename = '') { | |||
| $filename = \dokuwiki\Utf8\Clean::stripspecials($filename, '_'); | |||
|
|
|||
| // send CRLF to Windows clients | |||
| if(strpos($INPUT->server->str('HTTP_USER_AGENT'), 'Windows') !== false) { | |||
| $text = str_replace("\n", "\r\n", $text); | |||
| if(strpos($INPUT->server->str('HTTP_USER_AGENT'), 'Windows') !== false && $linefeed !== "Unix") { | |||
There was a problem hiding this comment.
I guess $linefeed is not defined.
There was a problem hiding this comment.
resolved, the function now has the linefeed as an argument and it defaults to ''
with a default value to avoid "not defined" situations
|
I don't really know how to fix the "overlap" thing you've mentioned. Where is that part coded in #2307 ? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
... for downloadable code blocks.
This is more a feature request than it is a pull request, but I've done it like this to easily show/allow others to modify the code. Underneath my changes, at line 34, I've put in a commented out alternative version, primarily to demonstrate an alternative approach.
I've been using Dokuwiki for a while to create and provide scripts for novice users to download and use for a small custom distribution based on Linux we are building that is typically deployed and edited on a remote network connection, using another computer to make those edits. This all works wonderfully well when downloading the files in a strictly Linux environment, however I've found out that users of Windows computers (which I've found out, is most of my reader's primary OS) were receiving these files with the incorrect CRLF line terminators. Looking through the web I found #863 , a change made around six years ago making DokuWiki automatically detect and change the line feed used in the downloaded file depending on the user's operating system. The actual commit merged that fixed it is #872 .
This is a neat feature, and I wouldn't want to undo that behaviour by default, but I would like to add a flag that editors can use to specify "hey, this is a Unix script, and the linefeeds need to remain untouched", so that neophyte users can simply download and use the script files as they are without having to do additional line feed conversions.
I'm aware that I'm changing the number of arguments that this function accepts, and that this would cause issues elsewhere, that's precisely why I'm asking for assistance here! I'm not a veteran DokuWiki coder, so please feel free to completely change this code, or close this pull request if it can be implemented in a much better way. The original PR I'm seeing that changed this behaviour in the first place only edited this file, so I'm not even sure where to begin looking for other files that might be calling this one, if there are any at all.