Version: (using KDE 4.2.96) Installed from: SuSE RPMs In kde4.2.96 kate, when you have a snippet that contains ansi escape code (say for color), when you use the snippet an input it into a document, kde4 kate incorrectly interprets the escape codes and "evaluates" the codes that royally screws up the document the snippet has been inserted into. Specifically, when I input my color snippet, the document turns lightgray and all returns then skip about 10 lines and backspace does the same thing. The specific snippet at issue was: <snippet start to show spacing> # ## colors - usage: ## echo -e "${red}..stuff...${nc}" or ## ${red} program ${nc} # black='\e[0;30m' # ${black} blue='\e[0;34m' # ${blue} green='\e[0;32m' # ${green} cyan='\e[0;36m' # ${cyan} red='\e[0;31m' # ${red} purple='\e[0;35m' # ${purple} brown='\e[0;33m' # ${brown} lightgray='\e[0;37m' # ${lightgray} darkgray='\e[1;30m' # ${darkgray} lightblue='\e[1;34m' # ${lightblue} lightgreen='\e[1;32m' # ${lightgreen} lightcyan='\e[1;36m' # ${lightcyan} lightred='\e[1;31m' # ${lightred} lightpurple='\e[1;35m' # ${lightpurple} yellow='\e[1;33m' # ${yellow} white='\e[1;37m' # ${white} nc='\e[0m' # ${nc} </snippet start to show spacing> This snippet inserts correctly in kde3 kate, but in kde4 it does not and causes the editor for the active document to go crazy. Screenshot and katesnippetspluginrc to follow.
Created attachment 35496 [details] screenshot showing effect of color snippet insertion in kde4 kate
Created attachment 35497 [details] .kde4/share/config/katesnippetspluginrc
Further, inserting snippet strips ${ } from the lines of code. Try defining the following snippet: usage() { echo -e "\n\tUsage: ${0##/*} <parameter>\n" echo -e "\t LINE 2 \n" exit 1 } When you insert it, the second line is inserted as follows: echo -e "\n\tUsage: 0##/* <parameter>\n" Kinda screws up bash parameter substitution doesn't it?
${} is used for template insertion. That is currently a littlebit broken in trunk. If you really want to insert ${} into a document try writing it as \${} in the snippet plugin
If ${asdf} should be inserted by the snippets or snippets_tng plugin it has to be escaped as \${asdf}, otherwise it is interpreted as template placeholder
WHOA JOSEPH -- what are you saying. That every user is to go redo every one of their kate snippets that work just fine in KDE3 but are now broken in KDE4 by escaping all of the \$. That's NUTS. As you say: <quote> That is currently a littlebit broken in trunk. </quote> You cannot seriously expect every kate snippet user to go change every snippet that has a $ in it because something is broken in snippets and somebody now doesn't want to take the time to fix it --- Do you? I'm not trying to be snippy or degrading, but logic of that approach to solving issues broken in kde4 -- completely escapes me. (no pun intended) Why should the entire community have to re-write all the snippets they have developed over the years? The truth is, "They shouldn't have to." Snippets that worked just fine in KDE3 should also work just fine in KDE4 and bugs introduced in KDE4 kate should not simply be swept under the rug and labeled "Works" when they in fact do not work. Don't take this the wrong way, I'm not trying to be argumentative, but I got to tell you, your closing of this bug without fixing the problem has caught me completely off-guard. This kind of thing completely destroys any confidence that KDE4 will ever provide a replacement for KDE3 without the users who move from KDE3 to KDE4 having to re-write years of work just to make things work again. Again, that's nuts. Very simply: AGAIN, save the following as a snippet: usage() { echo -e "\n\tUsage: ${0##/*} <parameter>\n" echo -e "\t LINE 2 \n" exit 1 } Then insert it: usage() { echo -e "\n\tUsage: 0##/* <parameter>\n" echo -e "\t LINE 2 \n" exit 1 } BROKEN Every single place where somebody has used any type of parameter expansion or substitution, or substring extraction, comparison or substitution is now broken. Thats 30% of BASH. Not fixing it is not an option.
The problem here is obvious, for years the auto variables in kate snippets were specified as: <date/> <time/> and everything peacefully coexisted. The somebody introduced the bug when they coded the insertion templates to use ${name} instead of the historic format of <name/>. (like ${date} ${time}) By using ${name} with insertion templates, the incompatibility bug was introduced. The beauty of the way snippets was originally developed using the <name/> format make perfect sense. There isn't any <name/> in BASH, c or anything else, so there was no possibility of conflict. Using the ${name} format wipes out just about everything in BASH because the basic variables, arrays, parameter and string operations ALL require the use of braces. So you have an automatic conflict. You wouldn't know who did that off-hand would you Joseph or Anders? Matters not, the important point is that it be fixed. You should be able to easily fix this problem by adding a simple test: if "inserting snippets"; then look for <name/> format don't strip braces else do whatever with the braces fi Why won't something as simple as this work? It would save thousands of man-hours of recoding snippets for users due to the introduction of the bug. Thanks.
As I'm now working on the template stuff, let me comment on it: 1) Joseph is right, you have to escape usage of ${...} 2) It won't take you "thousands of man-hours" to escape your snippets, they are all stored in files somewhere on your disk and you can easily run e.g. sed over them to escape your vars. This will take a few minutes most. 3) <VAR/> is imo even worse then ${...} as it conflicts with XML/HTML. Essentially you'd have to escape _every_ XML/HTML tag. And since the latter is also used in e.g. Doxygen it's ubiquotos. So <VAR/> is imo out of the discussion. 4) This is an old problem any template language has: It must have a syntax that does not interfer with it's contents. No matter what you choose, you'll have to escape something in one case or the other. 5) I don't know when this change was introduced, but my bet is the KDE3<->4 transition as Kate's Template Interface was introduced in 2004. Changing the Snippet format is suboptimal. Sure. But imo justified, if it is an improvement. And at least in my eyes it is. But this will be a matter of personal opinion. Depending on what languages you use the snippets for, one format or the other would be preferred. We cannot care for all. And ${...} syntax is "only" known to me in Bash, PHP and probably Perl. So imo, this is a wont-fix. And to show you my support, please tell me what Kate Plugin you use for snippets. Depending on that, I can tell you where the snippets are stored and could even write you a sed script to magically escape all occurrences of ${...}.
Hmm... It sounds like other issues of the transition from KDE3 to KDE4... Anyway: Would it be possible to add an option where one can switch between "old" and "new" style? I don't think that this is difficult to implement and it would assure the backwards compatibility. Thanks Karl
Since the KDE Developers have decided to leave kate snippets broken in kde4, I want the record clear. As of: Kate Version 3.3.4 Using KDE 4.3.4 (KDE 4.3.4) None of the BASH snippets containing standard dereferences of the form ${#VARNAME[]} or ${VARNAME##} or ${#VARNAME%%} work because kate in KDE4 strips the '${}' from when it inserts the snippets. I have a lot of broken snippets now. Thanks KDE! Example: THE ORIGINAL SNIPPET: ## basic function to trim (or stip) the leading & trailing whitespace from a variable ## passed to the fuction. Usage: VAR=$(trimWS $VAR) trimWS() { [[ -z $1 ]] && return 1 strln="${#1}" [[ strln -lt 2 ]] && return 1 trimSTR=$1 trimSTR="${trimSTR#"${trimSTR%%[![:space:]]*}"}" # remove leading whitespace characters trimSTR="${trimSTR%"${trimSTR##*[![:space:]]}"}" # remove trailing whitespace characters echo $trimSTR return 0 } SNIPPET INSERTED BY KATE (double-click on snippet name) ## basic function to trim (or stip) the leading & trailing whitespace from a variable ## passed to the fuction. Usage: VAR=$(trimWS $VAR) trimWS() { [[ -z $1 ]] && return 1 strln="#1" [[ strln -lt 2 ]] && return 1 trimSTR=$1 trimSTR="trimSTR#"${trimSTR%%[![:space:]]*"}" # remove leading whitespace characters trimSTR="trimSTR%"${trimSTR##*[![:space:]]"}" # remove trailing whitespace characters echo $trimSTR return 0 } If you want to have working snippets, dump the KDE4 version of kate and install the KDE3 version. It still inserts snippets properly. It just blows my mind that the new set of KDE developers simply closed this bug as 'WONT' fix. That speaks volumes about the new KDE.
What the hell David? Are you really serious? Do you think we are set out to brake stuff? Just for the fun of it? So that users can insult us on bug trackers? Is that really what you are telling? Did you even read what I wrote above? Have you ever tried to write a template language? Are you aware of the escape-problem? I find it really insulting and arrogant of you to write comments like this. "Thanks KDE!" You are welcome. And you know what: I'll even write you a script to convert your old snippets. But guess what: I just don't have the frikkin time right now. But I'll do it sooner or later. Just stay tuned. Oh and btw.: Escaping is currently broken. This has also to be fixed (no this part is definitely not a WONTFIX). And you know what? Maybe we'll even change the behavior some time. So that no escaping at all is required, but you'd have to mark variable-areas with the mouse. Which of course would not work with the current syntax. And would break existing Snippets. And it would change behavior of existing classes. So if at all, this would become an _additional_ interface to the current one, and definitely not before 4.5. Probably later.
For the record: I just fixed escaping in trunk.