richjyoung / vscode-modern-vhdl

Modern VSCode VHDL Support
MIT License
30 stars 12 forks source link

[Suggestion] Stuttering mode and Header Insertion (like Emacs' VHDL-mode) #3

Closed Mrcuve0 closed 5 years ago

Mrcuve0 commented 5 years ago

Hi! Thank you for this great (and up-to-date) extension, keep up the good work!

I'd like to propose two features coming from the great VHDL-mode integrated in Emacs, the "Stuttering mode" and the "Header insertion". Will it be possible to see them integrated in a next plug-in release?

I'll directly copy-paste the description you can find in the docs:

HEADER INSERTION: A file header can be inserted by ‘C-c C-t C-h’. A file footer (template at the end of the file) can be inserted by ‘C-c C-t C-f’. See customization group ‘vhdl-header’.

This is what (roughly) an inserted header looks like:


-------------------------------------------------------------------------------
-- Title      : <title_name_here>
-- Project    : <project_name_here>
-------------------------------------------------------------------------------
-- File       : <file_name_here>.vhd
-- Author     : <author_name>
-- Company    : <company_name_here>
-- Created    : 2019-03-08
-- Last update: 2019-03-09
-- Platform   : 
-- Standard   : VHDL'93/02
-------------------------------------------------------------------------------
-- Description: <insert_description_here>
-------------------------------------------------------------------------------
-- Copyright (c) 2019 
-------------------------------------------------------------------------------
-- Revisions  :
-- Date        Version  Author  Description
-- 2019-03-08  1.0    <auth>    Created
-------------------------------------------------------------------------------

STUTTERING: Double striking of some keys inserts cumbersome VHDL syntax elements. Stuttering can be disabled (enabled) by typing ‘C-c C-m C-s’ or by option ‘vhdl-stutter-mode’. Enabled stuttering is indicated by ‘/s’ in the mode line. The stuttering keys and their effects

;;   -->     " : "            [   -->  (          --    -->  comment
;;;  -->     " := "          [[  -->  [          --CR  -->  comment-out code
..   -->     " => "         ]   -->  )          ---   -->  horizontal line
,,   -->     " <= "         ]]  -->  ]          ----  -->  display comment
==   -->  " == "          ''  -->  \"

Thanks!

richjyoung commented 5 years ago

Thank you for the feedback, I appreciate your support!

With regard to header insertion, this is a useful feature but I think this could be better handled by VSCode outside the scope of this extension via user-defined snippets. This extension can also provide pre-defined snippets (which it currently does for certain design units, and other large statements), however it does not seem appropriate to define a header when the style will be very dependant on the user's style or mandatory coding standards.

Emacs stutter mode is not something I have come across before, but makes total sense. I think such a feature is possible via the CompletionProvider API. Few questions/thoughts I have so far:

I am still developing this extension so the set of features provided may change by the time I take the Preview flag off it, however feedback like this is exactly the reason it is published to the Marketplace in advance of being complete!

richjyoung commented 5 years ago

Try this: vscode-modern-vhdl-support-0.0.5-stutter-preview.zip

You will need to enable the following settings:

"editor.formatOnType": true,
"vhdl.enableStutterDelimiters": true,
"vhdl.enableStutterBrackets": true,
"vhdl.enableStutterComments": true

Further detail is in the README (should be accessible from the extension page, if not have a look here.

Let me know if you have any feedback, but otherwise this is something I'd be happy to release in the future.

Mrcuve0 commented 5 years ago

You are right about the header insertion, probably it is best to let the user decide and manage it's proper header layout. I'll take a look on how to create user-snippets since I didn't know there was this possibility.

Sorry for the late reply, I tried your preview and it's amazing, just like the Emacs version! I'm already loving it!

The only thing a little bit different is the one you already pointed out in your readme, it's really not a big issue:

Note: When inserting a display comment, the cursor will be left at the end of the final separator, rather than the middle of the block.

--------------------------------------------------------------------------------
-- Also, once you are here and you press return 
-- the original Emacs mode automatically adds this line, 
-- continuing the comment block automatically.
--------------------------------------------------------------------------------

Finally, the behavior of stuttering mode with autoClosingBrackets=languageDefined is, at a first glance, a little bit messy: still, once you understand the behavior the usage it's pretty straightforward.

I love the settings descriptions and the 3 different stuttering options, having more choice is always a great thing.

To me, this feature can be considered complete, love this extension, finally a great VHDL extension for VSCode!

jacopoabramo commented 5 years ago

Hi there, I just realized the new feature is on a separate branch; are you going to merge it to the master or you're planning something else for the 0.0.6?

jacopoabramo commented 5 years ago
--------------------------------------------------------------------------------
-- Also, once you are here and you press return 
-- the original Emacs mode automatically adds this line, 
-- continuing the comment block automatically.
--------------------------------------------------------------------------------

I agree that this would be an absolute blast of a feature to be implemented, since I'm always struggling to comment my code properly and auto-adding the two dashed lines would be perfect. I wanted to try and do some work with it yesterday, but for some reason the VS Code APIs that were installed in my home PC are not coherent with the APIs this extension used. Don't even know why.

richjyoung commented 5 years ago

I'd like to fix the display comment behaviour if I can, it seems at the moment the cursor is left at the end of all edits in the document buffer, rather than just at the end of the last applied edit. This is also the reason the autoClosingBracket behaviour is weird, as I can't replace the suggested bracket without leaving the cursor at the end of the line.

I've not actually used Emac so continuing the display comment on enter keypress is something I was not aware of, but would like to include this if I can. Does Emacs continue normal comments on an enter keypress?

Plan is to make this available in v0.0.6 as soon as the above issues are sorted, as I'm not an Emacs user I wanted to put a VSIX on this thread before merging just to make sure I understood the expected behaviour correctly.

richjyoung commented 5 years ago

@jethro33 I may have made a mistake with the engine version specified in the manifest. I don't suppose it generated any error logs when you tried to use it? I would expect a VSCode version equal or greater than 1.30.0 should work, but it would be good to know what version you had an error with as well.

Also as the version number has not been increased since the last release, I don't know if VSCode will replace a matching version, so you may need to uninstall any existing versions before trying the VSIX above.

jacopoabramo commented 5 years ago

@richjyoung right now I'm at work and I'm capable of debugging the extension with no problem; different thing is when I work at home. I can show you the error log as soon as I get back home.

I remember though that when I run the command

npm install

in order to load the VS Code typescript libraries within the extension folder, the detected VS Code version is 1.0.0, but I'm sure to have the latest release. It surely is a problem on my side, but I can't figure out what that is.

As for Emacs, I really can't tell you. I started using VS Code since I programmed in C/C++ and I kept using it also for VHDL. I never used Emacs, but if it has that feature described by @Mrcuve0 then I'd love to have it too.

richjyoung commented 5 years ago

@jethro33 If you are debugging it from the branch then I am sure the engine setting in package.json is causing issues. I changed it locally but did not commit the result by mistake. Try ^1.30.0 if I have not fixed it by the time you next have a go.

jacopoabramo commented 5 years ago

@richjyoung much obliged, I'll try it as soon as I got some time and I'll let you know. Maybe you should open an issue concerning this, in case someone else has a problem with it.

jacopoabramo commented 5 years ago

@richjyoung by the way I tried your new version with stutter mode on my machine and it seems to be working just fine, so thumbs up.

Mrcuve0 commented 5 years ago

Does Emacs continue normal comments on an enter keypress?

Do you mean a scenario like this one, right?

signal <= '0';  -- comment 
otherSignal <= '1';

No, a comment like this one is interrupted when you press the enter keystroke and the "normal" code flow is reverted back (so you will write the otherSignal line).

To me, the only thing left to review is the comment block behavior that we discussed above. The remaining additions seems pretty much similar/identical to what we can find in Emacs (I can't actually test it but I'm pretty sure it behaves like that)

richjyoung commented 5 years ago

@Mrcuve0 Similar to that scenario yes, for a comment at the end of a line of code I would not expect it to continue. However when the comment is on its own:

-- This could continue on a new line
-- in this case.

signal <= '0';  -- but not in this case.
otherSignal <= '1';

I suspect making this work will be similar to making display comments work correctly anyway.

jacopoabramo commented 5 years ago

Not sure if it makes sense, but in my opinion for comments like

signal <= '0'; -- optional comment

I find easier to just have a snippet which has a field of an optional comment. Maybe it's overkill, but declaring a comment for each assigned signal would make the code verbose (again, it's just my personal taste).

Mrcuve0 commented 5 years ago

@jethro33 I think that your solution is overkill. As a user I will probably disable it because it will destroy my "code flow" (since each single line the user inserts, the user itself will be automatically prompted to add a comment). This approach may simply be handled by the single developer that wants to, as we should avoid enabling it by default and forcing the developer to just "deal with it".

[Here I will probably go OT, maybe we should discuss about it in a new issue] Since I really like the approach to a verbose code, may I suggest to add comments in the snippets that you already defined in the previous pull request (like for example a description of an entity/arch/process etc...)?
This is also the snippet-related feature adopted in Emacs: each snippet has the option to add a comment to it. Something like this:

combinational_process :
  prefix: cproc
  description: Combinational Process 
  scope: source.vhdl
  body:
    - "${1:proc_name}: process(${2:sensitivity_list})\t\t -- ${3:<insert_comment_here>}"
    - "begin"
    - "$0"
    - "end process $1;"
richjyoung commented 5 years ago

Fixed the display comment issue and released as v0.0.6.

Thank you both for your input, feel free to create a new issue to continue the conversation, or if you find any bugs with the stutter-mode implementation.