gehdoc / vscode-textile-preview Goto Github PK

Textile Language Features: 0.3.8
VS Code: 1.42.1
Operating system: Fedora 30

Describe the bug

Visual studio "contributions" tab for this extension, miss translations.

To Reproduce

Steps to reproduce the behavior:

1. Go to 'Extension' page by clicking 'Extension' icon in the left side menu
2. Click on 'Textile language feature' extension
3. Click on 'Contributions' tab
4. The description column contain translations keys, like '%textile.style.dec%'.

Expected behavior

The description column should contain translated strings.

Additional context

in root tsconfig.json file, reactivate :

• noUnusedLocals,
• noUnusedParameters.

Textile Language Features: v1.3.22
VS Code: 1.80.1
Operating system: Debian 11

Describe the bug
As illustrated below, just for the first item of a bulleted list that is written in multiple lines, the preview is also rendering multiple lines. It is not the case for the next multi-line items.

To Reproduce
Steps to reproduce the behavior:

1. Enter textile below

* Item number 1 in
  two lines
* Item number 2 in
  two lines
* Item number 3 in
  two lines

* Item number 1 in two lines
* Item number 2 in
  two lines
* Item number 3 in
  two lines

2. Preview

Expected behavior
As rendered in https://textile-lang.com

• add travis CI
• Update CII

note : https://code.visualstudio.com/api/references/extension-manifest

Textile Language Features: v1.3.20
VS Code: 1.71.1
Operating system: Debian 11

Is there a way to keep the capital letters always the normal size?

Example:

This selects the previous code source line : 1 line above the clicked one.

Textile Language Features: 1.3.16
VS Code: 1.68.0
Operating system: Fedora 36

Describe the bug
PRE tags inserted as HTML in textile document are not highlighted in the preview.

To Reproduce
Insert some text to create a first paragraph, then a newline, then a HTML PRE tag with some text inside.
While you modify the text of the PRE tag, the text of the paragraph above that PRE tag is highlighted in the textile preview.

Expected behavior
While you modify the text of the PRE tag, the text of that PRE tag should be highlighted in the textile preview.

Additional context
Inspection of the webview content show that the PRE tags directy inserted as HTML code are not line-numbered, causing the bug.

Improvements :

• Create GitHub issues for the followings :
• more tests
• #28
• Add Codecov ? https://github.com/codecov/example-typescript-vscode-extension => update CII website
• generate Typescript declaration file for textile-js : improve and publish to textile-js repo.
• find a way to remove "node_modules" directory completly ?
• vscode-nls : use 1 file bundle
  Look there : microsoft/vscode-node-debug@c7e835f
  Note : it may be easyer to automatically split bundle.
• line-number support for at least :
  • block HTML (inside "pre"),
  • parseTable (WIP) :
    • need CSS for different vscode theme,
    • and selection-marker's height is not dynamic,
  • parseDefList
  • lists (WIP : selection-marker still too far at left + ordered/unordered doesn't have the same left padding)
• cleanup CSS (remove entierely textile-js.css ?)
• rebase textile-js on it's original repo :
  • I'm using my fork https://github.com/GehDoc/textile-js for now. I'm waiting an approval for this PR : borgar/textile-js#51.
  • If this PR is not accepted, I'll slowly maitain my fork. => I'm doing this, starting from March 2020
• use another textile engine, with Redmine Textile flavour support.
• export to HTML & PDF.

Textile Language Features: v1.3.23
VS Code: v1.81.1
Operating system: Debian 11

Describe the bug
The cells of the first row of a table are centered disregarding formatting characters.

To Reproduce
Use this and preview:

|_. Col1          |_=. Col2        |_.  Col3          |
|=.  col1 row1    |   col2 row1    |=.  col3 row1     |
|=.  col1 row end |   col2 row end |=.  col3 row end  |

Expected behavior
As rendered by textile-lang.com, just the second column is centered as specified by _=., the other two columns are not centered horizontally in the first row.

Additional context
This is what is currently rendered:

TODO : Remove notice, and update Roadmap

To be done last, before publishing first beta.

Between :

• tools/split_i18n_bundle.js
• gulpfile.js

most important = triaging projects : this repo, VSCode Makdown, Textile-js.

Don't forget to :

• add Contributing guide,
• and report it this to CII website.

Hello 👋 I'm from the VS Code team.

Recently, we have been exploring a security feature we refer to as Workspace Trust. This feature is intended to centralize and unify a security conscious decision required by a variety of VS Code features. With workspace trust, the user will be able to declare whether or not they trust the folder that is opened in VS Code before these features are executed.

Why you should care

We want to make sure that those users have a delightful experience with workspace trust and that includes extension authors deciding how much of their extension is supported in an untrusted workspace. Custom editors are special in that if they cannot at least render in an untrusted state then they will be replaced by a lightweight message telling the user to enable trust. This means that users of your extension will not be able to see their editors and there may even be cases of data loss.

Workspace Trust experience

You can enable the feature with the following setting security.workspace.trust.enabled. Once enabled, you will see the following dialog when opening folders in VS Code.

This dialog is important for allowing the user to make a decision early and understand the impact of their decision. Once you understand the feature, you may want to customize when to display the dialog using the setting security.workspace.trust.startupPrompt.

You can follow the development of Workspace Trust and provide feedback in issue #106488.

Workspace trust API

First off, all of what I am about to say can be found in issue #120251. That issue will include discussion of the feature and any updates to the feature.

The Workspace Trust extension API is now in stable. This allowed us to release the first cut of our guide for onboarding your extension to Workspace Trust. The API is small, so here is a quick look.

You can declare your extension to provide complete, partial or no support in untrusted workspaces using the untrustedWorkspaces capability in package.json.

The following example declares that the extension is supported completely in untrusted workspaces. In this case, the extension is enabled in untrusted workspaces.

"capabilities": {
  "untrustedWorkspaces": {
    "supported": true
  }
}

The next example declares that the extension is not supported in untrusted workspaces. In this case, the extension is disabled in untrusted workspaces.

"capabilities": {
  "untrustedWorkspaces": {
    "supported": false
  }
}

The third option is to declared limited support. There are three tools provided to you when you select the limited option.

First, if you have a setting that can be configured in the workspace but requires the workspace to be trusted in order to apply the workspace value, then you can include the setting using restrictedConfigurations array property in untrustedWorkspaces object. Doing so, VS Code will ignore the workspace value of these restricted settings when your extension reads these settings values using the VS Code Workspace Configuration API.

The following example declares the settings that are restricted in untrusted workspaces.

"capabilities": {
  "untrustedWorkspaces": {
    "supported": "limited",
    "restrictedConfigurations": [
      "markdown.styles"
    ]
  }
}

Next, you can also check and listen if the current workspace is trusted or not programmatically using the following API:

export namespace workspace {
  /**
   * When true, the user has explicitly trusted the contents of the workspace.
   */
  export const isTrusted: boolean;
  /**
   * Event that fires when the current workspace has been trusted.
   */
  export const onDidGrantWorkspaceTrust: Event<void>;
}

Lastly, you can hide commands or views declaratively with the isWorkspaceTrusted context key in your when clauses.

A far more detailed guide on how to onboard which will be updated as we receive feedback can be found in issue #120251.

Rollout plan

We are planning on enabling this by default in the near future (most likely next release). To prepare for that day, we want to work with you to allow your editor to work seamlessly alongside the trusted workspace experience

Our Asks

The main features that should work for custom editors in an untrusted folder is rendering, viewing, and saving (if applicable). After renewing your codebase, I believe that your extension does certain things that can be dangerous if the folder contents are malicious therefore I believe that limited is the best option.

Please let me know if you have any question or would like to meet up via voice chat as I would be happy to assist you in getting your extension ready for workspace trust!

Either :

• try https://docs.travis-ci.com/user/reference/windows/
• or, replace Travis-CI by Azure-Pipeline : https://code.visualstudio.com/api/working-with-extensions/continuous-integration

just before publishing release

• Some diff to triage;
• look at #18 for comments about CSS;
• after modification, check if #23 is still present.

Add :

• marketplace rating;
• animation(s);
• list of features;
• roadmap's summary

Correct behavior : in this case, it should focus the vscode tab containing this source.

Add the ability to copy the auto-generated ID of a headline, to use it as a hash to directly open a document at this chapter.

Today, you have to guess the ID slugified from the headline content.
Idea = provide a contextual menu in the source view ?

Look there : microsoft/vscode-node-debug@c7e835f

Note : it may be easyer to automatically split bundle.

This is a bug in textile-js library.
TODO : report it to the relevant repository, then maybe try to correct it.

Textile Language Features: 1.3.9
VS Code: 1.55.2
Operating system: Debian

Describe the bug
By inserting inline monospace texts between two @ signs, the preview does not show them really inline and adds newlines before and after.

To Reproduce
Steps to reproduce the behavior:

1. Type in: example @inline monospace@ text
2. Check the live textile preview
3. Expected:
   example inline monospace text
4. Observed:
   example
   inline monospace
   text

Applied, waiting for approval :

• github
• communitybridge
• leetchi

It should highlight the LI

• Automate git clone/checkout
• Ensure no other bug exists / no other feature miss

An indicator should highlight the first row.
It works correctly for all other lines.

few before publishing first release

List :

• textile.links.openLocation => OK
• textile.preview.breaks => OK
• textile.preview.fontFamily => OK
• textile.preview.fontSize => OK
• textile.preview.lineHeight => OK
• textile.preview.linkify' option => Won't support
  Not managed in textile-js library, nor on reference https://textile-lang.com
• textile.preview.markEditorSelection => OK
• textile.preview.openTextileLinks => OK
  Note : only after click from within preview window (no effect in editor window)
• textile.preview.scrollEditorWithPreview => OK
• textile.preview.scrollPreviewWithEditor => OK
• textile.styles => OK
• (this is not an option) 'slugify' => TODO #20
• textile.links.openLocation => OK
• textile.trace => OK
  Note : see output > textile

On 2019/10/07 :

• Make all links clickable in the source document (linkProvider)
• Paragraph folding :
  • headers
  • #regions in HTML comments
  • multi-line <LI>
  • HTML code blocks
• Generation of table of content
• Generation of table of symbols

• Webpacked files are missing from 'package' and 'publish' commands.
  Idea : Webpack should be called by gulp in the sequence, not by vscode task.
• Look at integration with nls :
  • https://github.com/microsoft/vscode-extension-samples/tree/master/webpack-sample
  • And, verify : https://code.visualstudio.com/api/working-with-extensions/bundling-extension