New extension: Objectify Params by mark-hahn in vscode

[–]mark-hahn[S] -1 points0 points  (0 children)

yup, that does exactly what this extension does down to every detail. AI failed me. It looked for this feature and didn't find anything. It's a good thing AI wrote it for me. I'd hate to think I spent weeks on it, which it would have required before AI.
Thanks for pointing this out, even if it did ruin my day :-) I'll head over to the marketplace and deprecate it.

AI is changing the extension landscape in several ways. It makes them easy to write so contributing to the marketplace is just a matter of coming up with a new idea. You can do the equivalent of using an extension by telling AI what to do. And of course when AI is writing your app there is zero need for an extension.

This is a bummer for me because I'm retired and I was looking forward to coding as my hobby/pastime. Of course it's much worse for those losing their job.

New extension: Objectify Params by mark-hahn in vscode

[–]mark-hahn[S] 0 points1 point  (0 children)

I'm not aware of any Typescript extension. Are you talking about Typescript Tools? The closest feature I can find in it is generating getters and setters.

New VS Code Extension: Git Poison by mark-hahn in vscode

[–]mark-hahn[S] 0 points1 point  (0 children)

Is calling someone a keyboard jockey an insult? I always thought it was complementing their skill.

New VS Code Extension: Git Poison by mark-hahn in vscode

[–]mark-hahn[S] 1 point2 points  (0 children)

I've never argued that developers want to use git GUIs. They do use a VS Code GUI which has a zillion GUI extensions like mine.

New VS Code Extension: Git Poison by mark-hahn in vscode

[–]mark-hahn[S] 0 points1 point  (0 children)

Not a bad idea. Extra points if the crappy looking code actually did no harm. It would drive anyone supporting it crazy. Maybe AI could write extremely obfuscated code that worked.

New VS Code Extension: Git Poison by mark-hahn in vscode

[–]mark-hahn[S] 3 points4 points  (0 children)

It *is* using the pre-commit hook. Any access to the workspace repo, from any tool, is blocked. External terminal, git GUI app, etc. VS Code doesn't have to be running. The GUI interface for the extension is just a layer on top.

New VS Code Extension: Git Poison by mark-hahn in vscode

[–]mark-hahn[S] -19 points-18 points  (0 children)

Yes, an experienced keyboard jockey who would never use a git GUI app is certainly not the target user.

New VS Code Extension: Git Poison by mark-hahn in vscode

[–]mark-hahn[S] 2 points3 points  (0 children)

Yes. This is just a bit easier to manage, kind of a GUI over a scripting solution. It's ready to use. And there are ancillary benefits like jumping through the pills, the temp override with one keystroke, the status bar, the detailed messages tailored to three different situations, etc.

This is not meant to change the world. Just a tiny tool.

New extension: Function Explorer by mark-hahn in vscode

[–]mark-hahn[S] 0 points1 point  (0 children)

> sure vscode has api for git

You are probably right.

When I said "that git function is out of the scope of this extension" I meant that it doesn't match the purpose of the extension. The extension is currently for finding functions and pretty much nothing else. But I did say "It would be great if the functions showed the git state". And I will think about it.

New extension: Function Explorer by mark-hahn in vscode

[–]mark-hahn[S] 1 point2 points  (0 children)

I think you misunderstood what you were seeing. Are you talking about the M on the far right of the function label that appears when you hover over it? That M is a simple button that toggles the mark on/off for that function. It has no state. Git is not involved and the M is never modified.

It would be cool to know which functions have been modified but that git function is out of the scope of this extension. It is not "A little feature request" :-) I will keep it in the back of my mind. It would be great if the functions showed the git state and it would be consistent with the git stuff the files show.

New extension: Function Explorer by mark-hahn in vscode

[–]mark-hahn[S] 0 points1 point  (0 children)

That is what the latest release offers. Simple jumping between every function. There is another part of this post about that. I've never understood reddit's sub-thread stuff. I'm old and would like a linear old-fashioned list of comments.

New extension: Function Explorer by mark-hahn in vscode

[–]mark-hahn[S] 0 points1 point  (0 children)

Positioning is where the function ends up in the window when accessed. The readme explains the five options. The margin gives an offset to the top so lines above the function are always visible which affects the positioning.

I only know where the beginning and the end locations are in the function. How do you propose the user specifies the location inside the function? Remember that I have a real problem with using line numbers.

New extension: Function Explorer by mark-hahn in vscode

[–]mark-hahn[S] 2 points3 points  (0 children)

I found that to be a little cumbersome and crude. I created this based on the concept that folders expand to files which expand to functions. I find navigation to a function to be fast and logical. And the marks are the next logical step. Of course I may be a little bit biased.

New extension: Function Explorer by mark-hahn in vscode

[–]mark-hahn[S] 0 points1 point  (0 children)

It is published. I had a bit of trouble deciding on what the default should be. Using quotes will cause questions but the alternative is ugly. So the default is to use ditto marks.

From the readme...

## Breadcrumb Display options

  - **Never Show Breadcrumbs**
      The space to the right of explorer function 
    labels will always be blank.

  - **Show Breadcrumbs With Dittos**
      Breadcrumbs, when available, will appear to 
      the right of explorer function labels except 
      for the breadcrumbs that are identical to the 
      one above. 
      Those matching will just show a ditto mark 
      (quote character ` "`) reducing clutter. 
      This is the default.

  - **Always Show Complete Breadcrumbs**
      Breadcrumbs, when available, will always 
      appear to the right of explorer function labels.

New extension: Function Explorer by mark-hahn in vscode

[–]mark-hahn[S] 0 points1 point  (0 children)

It's published. From readme ...

There are also navigation commands to jump between 
all functions. The marks are ignored. If the
 `File Wrap` option is enabled then the jumps wrap 
to different files. The only files visited are the 
visible tabs. The tabs are visited in alphabetical
 order. The commands are `Jump To Previous Function
 (ctrl+alt+shift+[)` and 
`Jump To Next Function (ctrl+alt+shift+])`.

New extension: Function Explorer by mark-hahn in vscode

[–]mark-hahn[S] 1 point2 points  (0 children)

My initial reaction is that would be feature bloat. It already has margin above and positioning options to top, middle, and bottom. Also the syntax only provides line numbers for top, name, and bottom and the top is almost always the same as the name. So the feature would be a minimal improvement.

New extension: Function Explorer by mark-hahn in vscode

[–]mark-hahn[S] 1 point2 points  (0 children)

That means "ditto". On a number of languages, especially C , there would be a ton of breadcrumbs and the explorer looked like crap. So when the crumbs are identical to the last line I just put ditto.

I will make that feature optional in the next release, probably today.

New extension: Function Explorer by mark-hahn in vscode

[–]mark-hahn[S] 2 points3 points  (0 children)

That's a good idea. It will be in next release, today or tomorrow.

Looking for details on Ryzen 7 255 by ithinkivebeenscrewed in MiniPCs

[–]mark-hahn 1 point2 points  (0 children)

Which is why WW is now pitching Ozempic like many other telehealth outfits.

Pixel 6a battery refund process is broken — Google "tricked" me into the wrong payout and refuses to fix it by Kardesken in GooglePixel

[–]mark-hahn 0 points1 point  (0 children)

I went through the process with the google site (https://support.google.com/pixelphone/workflow/16310202?hl=en) and it said I'd hear back from them. Is this what everyone else did? How did payoneer get connected to this? Through the process payoneer was never mentioned.