Allow forced highlighting for text from web interface

[k3d3]

There should be a dropdown somewhere (maybe beside the title?) that allows forcing the text to be syntax highlighed a certain way.

[ultramancool]

+1 we can always just go with the old hastebin method of appending an
extension or something.
On Aug 18, 2015 15:55, "Keith M" [email protected] wrote:

There should be a dropdown somewhere (maybe beside the title?) that allows
forcing the text to be syntax highlighed a certain way.

—
Reply to this email directly or view it on GitHub
#33.

[andre-d]

The plan is to just use the file extension to guess better...you can
already change the file extension
On Aug 18, 2015 4:02 PM, "ultramancool" [email protected] wrote:

+1 we can always just go with the old hastebin method of appending an
extension or something.
On Aug 18, 2015 15:55, "Keith M" [email protected] wrote:

There should be a dropdown somewhere (maybe beside the title?) that
allows
forcing the text to be syntax highlighed a certain way.

—
Reply to this email directly or view it on GitHub
#33.

—
Reply to this email directly or view it on GitHub
#33 (comment).

[k3d3]

I uploaded a file with .md earlier and it didn't highlight as markdown syntax

[ultramancool]

@k3d3 it's not implemented like that yet.

However @andre-d wouldn't it be better to put it somewhere that it can be changed? ex: if auto-detect fails.

[andre-d]

To clarify it does not yet use the extension to guess.
On Aug 18, 2015 5:39 PM, "Keith M" [email protected] wrote:

I uploaded a file with .md earlier and it didn't highlight as markdown
syntax

—
Reply to this email directly or view it on GitHub
#33 (comment).

[andre-d]

It can be changed
On Aug 18, 2015 5:44 PM, "Andre D" [email protected] wrote:

To clarify it does not yet use the extension to guess.
On Aug 18, 2015 5:39 PM, "Keith M" [email protected] wrote:

I uploaded a file with .md earlier and it didn't highlight as markdown
syntax

—
Reply to this email directly or view it on GitHub
#33 (comment).

[k3d3]

Ah, okay. Still, it would be nice to have a dropdown that defaults to "Detect" but allows forcing a certain syntax

[andre-d]

Gist uses the file extension to detect as well..seems needless to have
three methods of detection
On Aug 18, 2015 5:46 PM, "Keith M" [email protected] wrote:

Ah, okay. Still, it would be nice to have a dropdown that defaults to
"Detect" but allows forcing a certain syntax

—
Reply to this email directly or view it on GitHub
#33 (comment).

[k3d3]

What's the third method of detection? I wouldn't consider "manually pick" as a method of detection, if that's what you mean.

[andre-d]

1. automatic
2. mime type (going to be selectable for all files to support changing
   between display types..also as claimed by browser)
3. file extension (selectable and as uploaded if a file)
   On Aug 18, 2015 6:08 PM, "Keith M" [email protected] wrote:

What's the third method of detection? I wouldn't consider "manually pick"
as a method of detection, if that's what you mean.

—
Reply to this email directly or view it on GitHub
#33 (comment).

[andre-d]

File extension trumps mine which trumps automatic
On Aug 18, 2015 6:48 PM, "Andre D" [email protected] wrote:

1. automatic
2. mime type (going to be selectable for all files to support changing
   between display types..also as claimed by browser)
3. file extension (selectable and as uploaded if a file)
   On Aug 18, 2015 6:08 PM, "Keith M" [email protected] wrote:

What's the third method of detection? I wouldn't consider "manually pick"
as a method of detection, if that's what you mean.

—
Reply to this email directly or view it on GitHub
#33 (comment).

[ultramancool]

None of which can you change after upload...

[andre-d]

Both file and mine will be selectable so its stupid to also add a highlight
type
On Aug 18, 2015 6:49 PM, "Andre D" [email protected] wrote:

On binary files the extension is not considered and mime type is the only
determining factor which is why it needs to be selectable
On Aug 18, 2015 6:49 PM, "Andre D" [email protected] wrote:

File extension trumps mine which trumps automatic
On Aug 18, 2015 6:48 PM, "Andre D" [email protected] wrote:

1. automatic
2. mime type (going to be selectable for all files to support changing
   between display types..also as claimed by browser)
3. file extension (selectable and as uploaded if a file)
   On Aug 18, 2015 6:08 PM, "Keith M" [email protected] wrote:

What's the third method of detection? I wouldn't consider "manually
pick" as a method of detection, if that's what you mean.

—
Reply to this email directly or view it on GitHub
#33 (comment).

[k3d3]

Why do we detect via mime type? Half of the time it's text/plain anyways

[k3d3]

In any case, I don't feel like having 3 automatic detection methods really replaces one manual method. I'm not advocating we only have manual, but it should be an option.

[andre-d]

The detection I have planned (not currently) is:

1. is there a non txt extension which matches? Use that.
2. is there a text mine type which matches which is not text plain? Use
   that.
3. automatic

We should use mine type because it is the most standard and correct way to
identify the type of a file.

The user may always specify a mine type and file name.
On Aug 18, 2015 7:14 PM, "Keith M" [email protected] wrote:

Why do we detect via mime type? Half of the time it's text/plain anyways

—
Reply to this email directly or view it on GitHub
#33 (comment).

[ultramancool]

I'm really just going for https://up1.ca/#SEED.cpp, similar to what we had on hastebin

Users can't specify file name if they just upload a file via web or sharex.

[andre-d]

essentially what I am saying is that file extension and mine type manually
entered should cover any use cases that an additional "highlight type"
should cover.
On Aug 18, 2015 7:17 PM, "Andre D" [email protected] wrote:

The detection I have planned (not currently) is:

1. is there a non txt extension which matches? Use that.
2. is there a text mine type which matches which is not text plain? Use
   that.
3. automatic

We should use mine type because it is the most standard and correct way to
identify the type of a file.

The user may always specify a mine type and file name.
On Aug 18, 2015 7:14 PM, "Keith M" [email protected] wrote:

Why do we detect via mime type? Half of the time it's text/plain anyways

—
Reply to this email directly or view it on GitHub
#33 (comment).

[ultramancool]

@andre-d But they don't, we have no manual override for uploaded files that way.

[andre-d]

If you want a viewtype it should likely just be mime type in the URL rather
than a file extension to cover annoying cases like ogg vs ogv
On Aug 18, 2015 7:18 PM, "Andre D" [email protected] wrote:

essentially what I am saying is that file extension and mine type manually
entered should cover any use cases that an additional "highlight type"
should cover.
On Aug 18, 2015 7:17 PM, "Andre D" [email protected] wrote:

The detection I have planned (not currently) is:

1. is there a non txt extension which matches? Use that.
2. is there a text mine type which matches which is not text plain? Use
   that.
3. automatic

We should use mine type because it is the most standard and correct way
to identify the type of a file.

The user may always specify a mine type and file name.
On Aug 18, 2015 7:14 PM, "Keith M" [email protected] wrote:

Why do we detect via mime type? Half of the time it's text/plain anyways

—
Reply to this email directly or view it on GitHub
#33 (comment).

[andre-d]

I am not saying we do, but such a feature is planned and planning another
feature on top is silly.
On Aug 18, 2015 7:19 PM, "Andre D" [email protected] wrote:

If you want a viewtype it should likely just be mime type in the URL
rather than a file extension to cover annoying cases like ogg vs ogv
On Aug 18, 2015 7:18 PM, "Andre D" [email protected] wrote:

essentially what I am saying is that file extension and mine type
manually entered should cover any use cases that an additional "highlight
type" should cover.
On Aug 18, 2015 7:17 PM, "Andre D" [email protected] wrote:

The detection I have planned (not currently) is:

1. is there a non txt extension which matches? Use that.
2. is there a text mine type which matches which is not text plain? Use
   that.
3. automatic

We should use mine type because it is the most standard and correct way
to identify the type of a file.

The user may always specify a mine type and file name.
On Aug 18, 2015 7:14 PM, "Keith M" [email protected] wrote:

Why do we detect via mime type? Half of the time it's text/plain anyways

—
Reply to this email directly or view it on GitHub
#33 (comment).

[andre-d]

Talked on other channels:

1. is there an extension in the url? If so check if it matches an extension
   or mime type.

2. mime or extension other than text plain or txt

3. automatic
   On Aug 18, 2015 7:19 PM, "Andre D" [email protected] wrote:

I am not saying we do, but such a feature is planned and planning another
feature on top is silly.
On Aug 18, 2015 7:19 PM, "Andre D" [email protected] wrote:

If you want a viewtype it should likely just be mime type in the URL
rather than a file extension to cover annoying cases like ogg vs ogv
On Aug 18, 2015 7:18 PM, "Andre D" [email protected] wrote:

essentially what I am saying is that file extension and mine type
manually entered should cover any use cases that an additional "highlight
type" should cover.
On Aug 18, 2015 7:17 PM, "Andre D" [email protected] wrote:

The detection I have planned (not currently) is:

1. is there a non txt extension which matches? Use that.
2. is there a text mine type which matches which is not text plain? Use
   that.
3. automatic

We should use mine type because it is the most standard and correct way
to identify the type of a file.

The user may always specify a mine type and file name.
On Aug 18, 2015 7:14 PM, "Keith M" [email protected] wrote:

Why do we detect via mime type? Half of the time it's text/plain
anyways

—
Reply to this email directly or view it on GitHub
#33 (comment).