On 4/13/25 1:17 PM, Darrell Anderson via tde-users wrote:
uriously there is some kind of detection taking place
in TDE Kate. I
opened a shell script and Kate correctly selected Bash highlighting. I
changed the declaration to /bin/perl. Nothing happened but when I saved
the file Kate changed the highlighting to perl. Curiouser and curiouser
is when I did likewise to /bin/python, Kate retained the perl
highlighting. Returning the declaration to /bin/bash and saving saw Kate
return the highlighting to Bash.
The existence of the metainfos files might be a clue from years ago the
original developers did not have a useful or dependable detection
scheme. This is alluded to in the KDE 5 documentation mentioned above.
Confusing me is my original point. Some of the files I open are obvious
shell scripts with /bin/bash|sh in the declaration. If the existing TDE,
nee old KDE, detection scheme uses mimetypes, something like the file
command, then how does this detection fail with obvious shell scripts?
That is something I would have to look at the katepart code to begin to
understand enough to offer a guess on.
I think there are probably a few issues that were addressed in
Frameworks5/Plasma kate.
What I understand is you have the 2-part lookup. Extension and/or
mime-type. The problem with the mime type (x-shellscript in this case)
is that there has always been rough edges in KDE3/TDE handling of them
internally. I don't know if this is a corner-case memory leak issue or
list corruption, but I have seen the mime types get confused on a
regular basis.
Not that the "wrong" mime type gets presented, but that "no" mime type
is presented. This happens at least ever few months or so where when it
occurs, you can go though kcontrol file-association or konqueror
(rt.-click, then properties) and discover that the normal association
has just disappeared. (that can be on the the individual mime-type for
the file, or which group it belongs to, e.g. "application" or "text",
etc.)
This isn't a permanent corruption, a log out/in restores them (or
perhaps a "kbuildsycoca --noincremental" without log out/in). Granted, I
have my box up and running for sometimes weeks at a time (between kernel
updates) so there is a lot of chances for the corner-case to be hit.
This is where the mime type syntax highlight breaks down. I would say
the extension, mime-type algorithm works correctly 95-99% of the time
for me. And I too dislike always using extensions for scripts.
The disparity without an extension can be easily seen by a simple example.
1. open kate or kwrite,
2. enter a simple awk script with proper interpreter line, e.g.
#!/usr/bin/awk -f
{ print $2 }
3. save the file without extension as 'print2' (no highlighting)
4. copy/paste into new file (or save as) 'print2.awk' (highlighting)
The 'file' command has no problem identifying the file as an awk script
with or without the extension:
$ file tmp/awk/print2
tmp/awk/print2: awk script, ASCII text executable
But kwrite doesn't. So there apparently is no check of the 'file'
command, and without the extension, the newly saved file has no mime
type other than plain text.
Now from the menu, Tools->Hightlighting->Scripts->AWK will instantly
correct the the mime type seen for syntax highlighting and all is well.
However, closing the file without extension and then reopening in
kwrite, even using File->Open Recent, reopens with file without the
previously set highlighting association.
That is despite the file-open dialog showing print2 with the shellscript
icon. Somewhere there is a disconnect between the information QDir holds
from iterating over the directory to produce the listing in the
file-open dialog and whatever part of katepart triggers selecting the
proper syntax file. But, add the .awk extension and the syntax highlight
is applied just fine.
So somewhere there is a breakdown in the syntax highlight. If you find
out where, maybe we can come up with a patch to fix it. If I stumble
across where the breakdown is, I'll do likewise.
--
David C. Rankin, J.D.,P.E.