Open directly PDF file in Skim from Visual Studio Code (macOS) - macos

I am trying to open my PDF document with Skim from Visual Studio Code. I would like the View LaTeX PDF file command to open in Skim my PDF document and update it automatically. Unfortunately, when I click on the View LaTeX PDF file button, it does not open Skim.
I am forced :
To open Skim myself;
And then to open the PDF file;
When I do this, everything works fine. The file updates correctly each time I save the LaTeX file.
So I would like to be able to open Skim with the PDF document directly from Visual Studio Code. As I try to do at the beginning of the video.
Note that I have already read these questions SyncTex with Skim pdf viewer?, PDF Preview in Visual Studio Code and the documentation.
My configuration is the following:
macOS (12.1)
Visual Studio Code (1.63.0)
LaTeX Workshop plug-in (v8.22.0).
Skim 1.6.7 (137)
pdfTeX 3.141592653-2.6-1.40.22 (TeX Live 2021) kpathsea version 6.3.3
Latexmk, John Collins, 29 September 2020. Version 4.70b
settings.json
{
"workbench.colorTheme": "Cobalt2",
"editor.formatOnSave": true,
"[javascript]": {
"editor.formatOnSave": true
},
"[javascriptreact]": {
"editor.formatOnSave": true
},
"prettier.disableLanguages": [
"javascript",
"javascriptreact"
],
"workbench.startupEditor": "newUntitledFile",
"latex-workshop.intellisense.package.enabled": true,
"latex-workshop.intellisense.unimathsymbols.enabled": true,
"latex-workshop.latex.recipes": [
{
"name": "latexmk 🔃",
"tools": [
"latexmk"
]
},
{
"name": "pdflatex ➞ bibtex ➞ pdflatex`×2",
"tools": [
"pdflatex",
"bibtex",
"pdflatex",
"pdflatex"
]
}
],
"latex-workshop.latex.tools": [
{
"name": "latexmk",
"command": "latexmk",
"args": [
"-shell-escape",
"-synctex=1",
"-interaction=nonstopmode",
"-file-line-error",
"-pdf",
"-outdir=%OUTDIR%",
"%DOC%"
],
"env": {}
},
{
"name": "pdflatex",
"command": "pdflatex",
"args": [
"-synctex=1",
"-interaction=nonstopmode",
"-file-line-error",
"%DOC%"
],
"env": {}
},
{
"name": "bibtex",
"command": "bibtex",
"args": [
"%DOCFILE%"
],
"env": {}
},
{
"name": "latexmk",
"command": "latexmk",
"args": [
"-xelatex",
"-synctex=1",
"-interaction=nonstopmode",
"-file-line-error",
"%DOC%"
]
}
],
"latex-workshop.latex.clean.subfolder.enabled": true,
"git.autofetch": true,
"terminal.integrated.fontFamily": "Inconsolata for Powerline",
"latex-workshop.view.pdf.viewer": "external",
"editor.minimap.enabled": false,
"editor.suggestSelection": "first",
"vsintellicode.modify.editor.suggestSelection": "automaticallyOverrodeDefaultValue",
"files.exclude": {
"**/.classpath": true,
"**/.project": true,
"**/.settings": true,
"**/.factorypath": true
},
"editor.codeActionsOnSave": {
"source.fixAll.eslint": true
},
"workbench.iconTheme": "material-icon-theme",
"prolog.executablePath": "/Applications/SWI-Prolog.app/Contents/MacOS/swipl",
"python.languageServer": "Microsoft",
"editor.wordWrap": "on",
"latex-workshop.view.pdf.zoom": "page-fit",
"latex-workshop.view.pdf.external.viewer.args": [
"0",
"%PDF%"
],
"latex-workshop.view.pdf.external.viewer.command": "/Applications/Skim.app/Contents/SharedSupport/displayline",
"latex-workshop.view.pdf.external.synctex.command": "/Applications/Skim.app/Contents/SharedSupport/displayline",
"latex-workshop.view.pdf.external.synctex.args": [
"-r",
"-b",
"%LINE%",
"%PDF%",
"%TEX%"
],
"latex-workshop.latex.autoBuild.cleanAndRetry.enabled": true,
"latex-workshop.latex.autoClean.run": "onBuilt",
"latex-workshop.latex.clean.fileTypes": [
"*.aux",
"*.bbl",
"*.blg",
"*.idx",
"*.ind",
"*.lof",
"*.lot",
"*.out",
"*.toc",
"*.acn",
"*.acr",
"*.alg",
"*.glg",
"*.glo",
"*.gls",
"*.ist",
"*.fls",
"*.log",
"*.fdb_latexmk",
"*.snm",
"*.nav",
"*.synctex.gz",
"*.run.xml",
"*.bcf",
"__latexindent_temp.tex"
],
"explorer.confirmDelete": false,
"latex-workshop.latexindent.path": "/usr/local/texlive/2021/bin/universal-darwin/latexindent",
"security.workspace.trust.untrustedFiles": "open",
"editor.fontSize": 16
}

So...In fact, the problem does not come from the setting file. It is well formed and valid. The problem is a scripting support bug in Monterey12.1. The sdef parser can't handle synonyms. This has been documented here.
A workaround while waiting for an update is to edit the file /Applications/Skim.app/Contents/Resources/Skim.sdef and comment these lines of code
<!-- <synonym name="selection for"/> -->
<!-- <synonym name="get preferences"/> -->
It's not the kind of solution I like, but, in the meantime, it does the job here at first.

Related

NW.js Windows 10 Taskbar icon shows always default

In Windows 10 the taskbar is not showing my custom-made icon. I am using the latest (at the moment of writing) 0.51.1 version of nw.js and the taskbar icon always defaults doesn't matter what I am doing. Even though the .exe icon is changing on the build and behaves as expected.
Have anyone managed to solve this issue? I read almost all issues log on this topic on the official nw.js Github page but it doesn't help and seems like the issue still happens for some users.
here is my package.json file
{
"name": "com.domain.product",
"version": "0.1.0",
"build": {
"nwVersion": "0.51.1",
"nwFlavor": "normal",
"strippedProperties": [ "scripts", "devDependencies", "build", "chromium-args"],
"mac": {
"name": "Product Name",
"icon": "ProductName.icns"
},
"win": {
"name": "ProductName",
"icon": "icon/ProductName.ico"
},
"output": "../build"
},
"window": {
"width": 314,
"height": 660,
"frame": false,
"transparent": true,
"toolbar": false,
"resizable": false
},
"main": "index.html",
"node-remote": [ "<all_urls>"]
}
Here is a more complex example, but look for how icons are handled in the the window setting and in the build settings:
https://github.com/nwutils/nw-vue-cli-example/blob/master/package.json
You need to add the 'window.icon' property to your package.json. Something similar to:
"window": {
"icon": "./build/my-icon.png"
},
See the Manifest format documentation for more details: https://nwjs.readthedocs.io/en/latest/References/Manifest%20Format/#icon

having trouble debugging a C file in vscode

I have a C file that I'm trying to debug but fail.
I'm using vscode on windows 10.
The file is quite large so I don't want to copy it here.
This is how my launch.json file looks in the .vscode folder in the folder that I'm working in:
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/? linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "gcc.exe build and debug active file",
"type": "cppdbg",
"request": "launch",
"program": "${fileDirname}\\${fileBasenameNoExtension}.exe",
"args": [],
"stopAtEntry": false,
"cwd": "${workspaceFolder}",
"environment": [],
"externalConsole": false,
"MIMode": "gdb",
"miDebuggerPath": "C:\\MinGW\\bin\\gdb.exe",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
],
"preLaunchTask": "gcc.exe build active file"
}
]
}
This is how my tasks.json looks like in the same .vscode folder:
{
"tasks": [
{
"type": "shell",
"label": "gcc.exe build active file",
"command": "C:\\MinGW\\bin\\gcc.exe",
"args": [
"-g",
"${file}",
"-o",
"${fileDirname}\\${fileBasenameNoExtension}.exe"
],
"options": {
"cwd": "C:\\MinGW\\bin"
}
}
],
"version": "2.0.0"
}
when I press the "start debugging" button the screen freezes and the program stalls and then vscode crashes
I managed to find a solution, I deleted the old files, clicked debug, it wanted me to create a new configuration, chose gcc launch and then there was an option 'gcc.exe build and debug active file' , clicked it, and now everything works.
I've updated the content of the files above to how they look right now if anyone has the same issue in the future.

VS Code, GDB remote debugging and Linux/Windows path characters

Simple question I hope. I'm using VS Code with the C/C++ extension running on Windows for remote debugging an ARM Cortex M0 board via OpenOCD running on Linux. This all works wonderfully well, with a single exception: path characters.
The problem is the ${workspaceFolder} macro. Since VS Code is running on Windows it seems to always use \ as a path delimiter. See error picture below. Obviously hardcoding the full path using / works but makes the launch.json highly machine specific.
Anyone know how to remap the path character?
TAIA.
launch.json for anyone who wants a working reference:
{
"version": "0.2.0",
"configurations": [
{
"name": "Debug",
"type": "cppdbg",
"request": "launch",
"logging": { "engineLogging": true },
"program": "R:/src/embedded/mcuxpresso/ASCH5_LPC/flash/ASCH5_LPC.axf",
"stopAtEntry": false,
"miDebuggerPath": "r:/apps/gcc-arm/bin/arm-none-eabi-gdb.exe",
"MIMode": "gdb",
"targetArchitecture": "arm",
"launchCompleteCommand": "exec-run",
"setupCommands": [
{ "text": "-target-select remote 192.168.1.99:3333", "description": "connect to target", "ignoreFailures": false },
{ "text": "-file-exec-and-symbols R:/src/embedded/mcuxpresso/ASCH5_LPC/flash/ASCH5_LPC.axf", "description": "load file", "ignoreFailures": false}, // this works
//{ "text": "-file-exec-and-symbols ${workspaceFolder}/flash/ASCH5_LPC.axf", "description": "load file", "ignoreFailures": false}, // this does not ...
{ "text": "-interpreter-exec console \"monitor reset\"", "ignoreFailures": false },
{ "text": "-interpreter-exec console \"monitor halt\"", "ignoreFailures": false },
{ "text": "-interpreter-exec console \"monitor arm semihosting enable\"", "ignoreFailures": false },
],
"externalConsole": true,
"cwd": "${workspaceFolder}"
}
]
}

How can I get vs code debugger to find map files for debugging angular-cli webpack project

I am working on an angular-cli v1.0.5 (angular 4) project. Below is the output of the ng -v command.
#angular/cli: 1.0.5
node: 6.10.3
os: win32 x64
#angular/common: 4.1.3
#angular/compiler: 4.1.3
#angular/core: 4.1.3
#angular/forms: 4.1.3
#angular/http: 4.1.3
#angular/platform-browser: 4.1.3
#angular/platform-browser-dynamic: 4.1.3
#angular/router: 4.1.3
#angular/cli: 1.0.5
#angular/compiler-cli: 4.1.3
I am also using;
Typescript version 2.3.4
Webpack version 2.2.1
Chrome Version 58.0.3029.110 (64-bit)
Windows 10
VS Code version 1.13.0
Debugger for Chrome version 3.1.2
I am trying to get debugging to work in VS Code but all of my breakpoints are dimmed and when I hover over them, I get the message "Breakpoint ignored because generated code was not found."
Directory Structure - My project starts in the masclient folder. This is where my package.json and angular-cli.json files are at. Within the masclient folder, I have a src folder and within the src folder, I have an app folder. My angular 4 app.module.ts is in this folder. All of my components are in their own folders below the app folder. The specific typescript file I am trying to debug is in the masclient\src\app\bulk-labels\create-bulk-labels folder
My launch.json file is shown below;
{
"version": "0.2.0",
"configurations": [
{
"name": "LaunchChrome",
"type": "chrome",
"request": "launch",
"url": "http://localhost:4200",
"sourceMaps": true,
"webRoot": "${workspaceRoot}/src",
"diagnosticLogging": false,
"userDataDir": "${workspaceRoot}/.vscode/chrome",
"sourceMapPathOverrides": {
"webpack:///C:*": "c:/*"
}
},
{
"name": "AttachChrome",
"type": "chrome",
"request": "attach",
"port": 9222,
"sourceMaps": true,
"webRoot": "${workspaceRoot}/src",
"diagnosticLogging": true,
"sourceMapPathOverrides": {
"webpack:///*": "/*"
}
}
]
}
My angular-cli.json is shown below;
{
"$schema": "./node_modules/#angular/cli/lib/config/schema.json",
"project": {
"name": "masclient"
},
"apps": [
{
"root": "src",
"outDir": "dist",
"assets": [
"assets",
"favicon.ico"
],
"index": "index.html",
"main": "main.ts",
"polyfills": "polyfills.ts",
"test": "test.ts",
"tsconfig": "tsconfig.app.json",
"testTsconfig": "tsconfig.spec.json",
"prefix": "masc",
"styles": [
"../node_modules/bootstrap/dist/css/bootstrap.min.css",
"styles/vendor.scss",
"styles/main.scss"
],
"scripts": [
"../node_modules/jquery/dist/jquery.min.js",
"../node_modules/tether/dist/js/tether.min.js",
"../node_modules/bootstrap/dist/js/bootstrap.min.js"
],
"environmentSource": "environments/environment.ts",
"environments": {
"dev": "environments/environment.ts",
"prod": "environments/environment.prod.ts"
}
}
],
"e2e": {
"protractor": {
"config": "./protractor.conf.js"
}
},
"lint": [
{
"project": "src/tsconfig.app.json"
},
{
"project": "src/tsconfig.spec.json"
},
{
"project": "e2e/tsconfig.e2e.json"
}
],
"test": {
"karma": {
"config": "./karma.conf.js"
}
},
"defaults": {
"styleExt": "scss",
"component": {}
}
}
My tsconfig.json file is shown below;
{
"compileOnSave": false,
"compilerOptions": {
"outDir": "dist/out-tsc",
"baseUrl": "src",
"sourceMap": true,
"declaration": false,
"moduleResolution": "node",
"emitDecoratorMetadata": true,
"experimentalDecorators": true,
"target": "es5",
"typeRoots": [
"node_modules/#types"
],
"lib": [
"es2016",
"dom"
]
}
}
I have gone through several recommendations I have found on Google with no luck. Most seem to refer to the process before angular-cli switched to webpack. There seem to be a lot of variation of property settings in the launch.json file. As I read through the posts before deciding to post my own question here, it seems that the issue may be related to the fact that the ng serve process keeps all of the compiled files in memory rather than pulling the map files from a ./dist folder... but I am not sure how that would change the location settings in the launch.json file.
I start debugging using the following process;
Run ng serve from the command line to start the web server
From within VS Code, I go to the Debug section and click on the green arrow next to "Launch Chrome" ( or press F5)
I have also tried this process;
Run ng serve from the command line to start the web server
Launch chrome.exe --remote-debugging-port=9222 from an admin level command prompt.
In the instance of Chrome that launched, navigate to locaohost:4200
From within VS Code, I go to the Debug section and click on the green arrow next to "Launch Chrome" ( or press F5)
With either of the startup methods listed above, wile viewing my source code *.ts files in the VS Code editor, I can see that my breakpoints are grayed out as soon as the debugger starts.
I am sure it probably just a matter of getting my settings in the various config files synced properly, but after several hours of research, the actual solution has eluded me.
Any help would be greatly appreciated.

VScode compile C++ on windows the exe not found

I want to ask how to debug a simple hello world output from a C++ file, on the launch file I have to put the executable but I have only created a C++ file, how to compile it, I have tried everything, please help.
{
"version": "0.1.0",
"command": "g++",
"isShellCommand": true,
// compiles and links with debugger information
"args": ["-g", "-o", "main.exe", "main.cpp"],
// without debugger information
// "args": ["-o", "hello.exe", "hello.cpp"],
"showOutput": "always"
}
Pretty old question but here's a clear explanation for anyone in future.
Issue is that the debugger was looking for a.exe but your build file will probably be named different.
Changing the values of program variable to "${workspaceFolder}\\${fileBasenameNoExtension}.exe" will fix this issue. This should be in the tasks.json and the launch.json.
This env variable takes care that the right name is substituted. Now set a breakpoint and press f5.
Further details here and here.
Here's a full preview of a working launch.json
"configurations": [
{
"name": "(gdb) Launch",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceFolder}\\${fileBasenameNoExtension}.exe",
"args": [],
"stopAtEntry": false,
"cwd": "C:\\MinGw\\bin",
"environment": [],
"externalConsole": false,
"MIMode": "gdb",
"miDebuggerPath": "C:\\MinGw\\bin\\gdb.exe",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
},
{
"description": "Set Disassembly Flavor to Intel",
"text": "-gdb-set disassembly-flavor intel",
"ignoreFailures": true
}
]
}
And a full preview of tasks.json.
"tasks": [
{
"type": "cppbuild",
"label": "C/C++: g++.exe build active file",
"command": "C:\\MinGW\\bin\\g++.exe",
"args": [
"-fdiagnostics-color=always",
"-g",
"${file}",
"-o",
"${fileDirname}\\${fileBasenameNoExtension}.exe"
],
"options": {
"cwd": "${fileDirname}"
},
"problemMatcher": [
"$gcc"
],
"group": {
"kind": "build",
"isDefault": true
},
"detail": "Task generated by Debugger."
}
],
"version": "2.0.0"
NOTE: As explained here and here, you might want to set "externalConsole": true if your code needs input from user.

Resources