Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

The automatic completion makes a double inferior quote in ST3 #23

Closed
swirly opened this issue Feb 11, 2016 · 5 comments
Closed

The automatic completion makes a double inferior quote in ST3 #23

swirly opened this issue Feb 11, 2016 · 5 comments

Comments

@swirly
Copy link

swirly commented Feb 11, 2016

In ST3, the automatic completion propose for <bo to add the body tag
(automatic completion first default line : body .... )
but the result is

<

with two opening tags

Does not happen if HTML is disabled

if HTML5 is enabled and HTML disabled, nothing is working
@jmenglis
Copy link

jmenglis commented Mar 1, 2016

I concur with Swirly. I have seen this same issue with both HTML5 and HTML enabled. The problem with disabling HTML is that all the syntax highlighting in Sublime disappears.

@ctf0 ctf0 mentioned this issue Mar 27, 2016
Closed
@ghost
Copy link

ghost commented Mar 28, 2016

This "double quote" problem trashes ST3 on PC and Mac for inline HTML coding. It is actually ST2 and ST3 issue (severity sometimes depending on OS/WIN Cloud Service relationships) that may have something to do with the PY authors (i.e., developers building Sublime Text) pushing through development that damages "entry level" code entry. Namely, built-in HTML snippets corrupt Sublime HTML code, by auto insertion of additional character, as described below (see below, historical information).
Regardless of cause, the ISSUE IS THIS:

<div>

entered manually remains as entered, a healthy div element HTML tag.
However,

<d

and then coder selection of any of the cursor drop-down built in '<tag>' snippets,
consistently inserts the additional character, namely:

<<div>

Now, when this problem first appeared in ST2, one did not have to use the snippets,
just closing any HTML element tag did auto-insert the corrupt additional code character,
as described above.
Today, this corruption is found upon use of the snippet functionality,
in entry of any and all HTML element tags inside of the <body> tag.
Here is the description of the corrupt character auto-inserted by every default Sublime configuration:

LESS-THAN SIGN
Sublime script: wtf knows?
Latin: left carat symbol
HTML: <, &lt, &lt ;
Unicode: U+003C, UTF-8: 3C
Hex: &#x0003c
Dec: &#60

That is, assuming use of the default expected Sublime configuration (as shipped) then
whenever built in HTML snippets are accessed by all users from code insertion point,
then corrupt by default, Sublime auto inserts the additional opening Left Carat symbol.
This corrupt Sublime auto insertion of << can be just 50% of HTML < characters typed into Sublime code.
Most often it is most, if not all HTML element opening tags inside of the <body> tag
(all opening tags are corrupted by Sublime).
Though, addition of any Package (including HTML5 Package),
definitely worsens the default Sublime corruption.

This leaves the Sublime HTML coder in the unfortunate predicament that the cursor '|' is at
the far right of the element-attribute tag,
while the incorrectly inserted additional left carat is at
the far left of the element-attribute tag!
Auto inserting of the extra left carat occurs in Sublime HTML coding like this:

<<div>|
and
<<div attribute="something">|
or, given a { word-wrap: break-word; },
<<a href="https://www.google.ca/search?q=very+long+html+link&client=safari&rls=en&source=lnms&tbm=isch&sa=X&ved=0ahUKEwj18q72_OLLAhVM1GMKHYtRDgEQ_AUIBygB"
style="colour: red;
content: "(" attr(href) ")";
font-size: 0.9rem;
font-weight: 700;
letter-spacing: 0.13ex;
list-style-image: url(http://example.org/pix/checkmark.png);"> |
[hey stoopid monkey, you beginning to dig our pissed-off "attitude"]

This crap HTML coding has been a problem in Sublime for years, literal years!
Now, if you ask me, an "entry level" coder for life,
this is brain dead on the part of the Sublime App developers - well, yes? No?
Okay, but they are obviously PY-BLIND,
and cannot see how they have mangled Sublime Text,
as their "entry level" coding product cannot shake a simple but serious problem.
Or perhaps they can see what they have done, and don't give a shit.
"Don't give a shit!" is definitely the tenure of Sublime developers at GitHub,
interacting with my requests (arrogant, ignorant PY-BLIND developers).
Microsoft senior engineers, who referred me to Sublime, were "GUM-FUK'd".

In all fairness, the PY-BLIND may be stuck where we all code due to environment.
Or, the brain-dead PY-BLIND developers may all be sharing some
secret plug-in or package that removes the HTML coding corruption,
on their highly privileged devices.
Then again, they could be too thoughtless to look outside some kind of paranoid shell.
And, in all fairness, they could be not only assailed and maladjusted persons,
but they could honestly feel,

"Shit on them all! They could always be running after
Edit, Replace, <<, tab, <, over-and-over all day long
so they can preview their puny work!"

You thunk?

Fact is, Sublime's a spastic mess for all HTML coders using default Sublime configuration.
Let's don't forgive our frustration, and leave it at that.
Let's fix that corrupt HTML auto-insertion of the corrupt opening HTML tag character.
That's all affirmative here. You, @mrmartineau ?

@cmalard
Copy link

cmalard commented Jul 14, 2017

Hello there,
Could this be fixed with the ST3 .sublime-syntax files ?

@resende1776
Copy link

Same problem here.

Edit, Replace, <<, tab, <, over-and-over

It keeps killing me, but that's all I got

@KonradBartu
Copy link

Don't type the opening bracket:
i.e.
<h1 + tab
Instead just type:
h1 + tab
Autocompletion will work and you won't get the extra <

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@mrmartineau @cmalard @swirly @resende1776 @jmenglis @KonradBartu