Hide extension column?

[caneb]

When set to show the file name extension directly after the file name, the Ext column stays visible. Is there any way to completely remove/hide it?

I tried making a custom columns view, but the extension column is greyed out and can't be removed there either.

[Balderstrom]

The only way to almost hide it is to reduce the Column/Tab-Stop size, but no matter how small you make it - the extension Column will be reset to a minimum of 5.

Mr.Ghisler has stated in previous posts the reason for the Name/Ext forced display has to do with efficiency of sorting/displaying the list... except that doesn't make sense to myself and others as that info could be kept internally - even if it wasn't force-displayed.

[ghisler(Author)]

No, the reason why the header is displayed is that you can SORT by extension by clicking on the header! Since the name is NOT cut where the ext column starts, there is no need to remove the header.

[jjk]

No, the reason why the header is displayed is that you can SORT by extension by clicking on the header! Since the name is NOT cut where the ext column starts, there is no need to remove the header.

I agree perfectly. This is a good point (another one...) for TC.
Most of the other filemanagers which are able to display name.ext without extension column do not display the virtual Ext column header, so there is no possibility to sort on extension by mouse.

[Balderstrom]

No, the reason why the header is displayed is that you can SORT by extension by clicking on the header! Since the name is NOT cut where the ext column starts, there is no need to remove the header.

But that doesn't explain why we can't make a custom column that doesn't have Name/Ext fields, or move them to not the 1st/2nd position, nor hide them... Which has been requested before.

[ghisler(Author)]

The reason why I implemented it this way was that I wanted to prevent people from creating views with e.g. just the file size. This would be very confusing, and you could accidentally delete important files. Of course it would be useful to replace these fields by your own, but I couldn't find a method which is both safe and powerful. I would have to detect somehow that the user added a field equivalent to the name himself...

[comrade]

I am working on a file system plugin where the extension column does not apply. For custom views for file system plugins, is it possible to lift the restriction of fixing the name+ext columns? Even the name column does not really apply (it is supplanted by a different, custom column).

[nsp]

The reason why I implemented it this way was that I wanted to prevent people from creating views with e.g. just the file size. This would be very confusing, and you could accidentally delete important files.

Why do you want to prevent user to do something ? Even if it is confusing for you !
In my case, i use a lot a custom column to show full path+name+ext => but still cannot remove those unnecessary columns that takes spaces.
I also use a custom column view for music where i list Artist, Year, Album, track N., Title, duration => in this case also file name/ext is not needed... (TC is my music library manager )
if my files are not tagged, i switch back and do it from a more conventional view

Of course it would be useful to replace these fields by your own, but I couldn't find a method which is both safe and powerful. I would have to detect somehow that the user added a field equivalent to the name himself...

If you take that much care of TC user, you can even add a file mode attached to the column view that warn/prevent you if you move/rename delete any file. This would be more convenient as you will not limit freedom and at the same time care of our filesystem health
Why do you want to detect anything you still have all you need internally and that would not be a big deal to HIDE/DISSABLE those columns ?

[_hunter]

The reason why I implemented it this way was that I wanted to prevent people from creating views with e.g. just the file size. This would be very confusing, and you could accidentally delete important files. Of course it would be useful to replace these fields by your own, but I couldn't find a method which is both safe and powerful. I would have to detect somehow that the user added a field equivalent to the name himself...

In this case you should remove "delete" functionality from TC: because you could accidentally delete important files.
Also you need to remove "copy" functionality from TC: you could accidentally overwrite important files.
And don't forget to remove "edit" functionality: you could accidentally edit something in important files.

The only thing you need to do (if you're worrying so much about "confusing" columns) -- just add new option somewhere in depth of Misc. -- like "I'm not getting confused with columns" (unchecked by-default).

[Lefteous]

The reason why I implemented it this way was that I wanted to prevent people from creating views with e.g. just the file size. This would be very confusing, and you could accidentally delete important files. Of course it would be useful to replace these fields by your own, but I couldn't find a method which is both safe and powerful. I would have to detect somehow that the user added a field equivalent to the name himself...

I think the rule should be that there must be one element visible that helps to identify an element. This element must be unique internally. But this element doesn't have to be a combination of name and extensions necessarily.

[nsp]

I think the rule should be that there must be one element visible that helps to identify an element. This element must be unique internally. But this element doesn't have to be a combination of name and extensions necessarily.

It is verry difficult to find a rule as even if we manipulate files, sometime the file represents some data where filename+ext is not usefull to identify the content. With Custom column and custom View TC is able to manipulate more than simple file. It is even possible to have for a custom view a combination of colums that defind a "key" that could be used to warn when you delete....

A TC user should be warned once that the view can be not safe and decide if he want to take the risk or not with his own files. You can have a strong warning and even have the abilty to remove it in some "expert mode" using a TC ini setting.

[_hunter]

Any official "opinion" on this? -- Are there any plans to fix this bug?

[Lefteous]

2nsp

It is verry difficult to find a rule

I think it's not that complicated. It's a unique identifier in a container. Sounds doable to me.

[nsp]

2nsp

It is verry difficult to find a rule

I think it's not that complicated. It's a unique identifier in a container. Sounds doable to me.

My point is that TC cannot guess if the column definition will contain this kind of ID. TC should anyhow continue to handle internally filename and consider panel with custom columns just as a view that display what the user want !

[_hunter]

2nsp

It is verry difficult to find a rule

I think it's not that complicated. It's a unique identifier in a container. Sounds doable to me.

My point is that TC cannot guess if the column definition will contain this kind of ID. TC should anyhow continue to handle internally filename and consider panel with custom columns just as a view that display what the user want !

It's absolutely possible to use "invisible" filename column. Not sure if it's worth disusing, though...