When running:
$ clang-format -style=Google -dump-config > .clang-format
The file is appended by a ellipsis (...).
TabWidth: 8
UseTab: Never
...
Does it have any significance? Can I delete it? Someone is asking what it means in a code review.
https://clang.llvm.org/docs/ClangFormatStyleOptions.html says:
The .clang-format file uses YAML format
http://www.yaml.org/refcard.html says:
'...': Document terminator.
Some more from http://yaml.org/spec/1.2/spec.html:
YAML uses three dashes (“---”) to separate directives from document
content. This also serves to signal the start of a document if no
directives are present. Three dots ( “...”) indicate the end of a
document without starting a new one, for use in communication
channels.
Related
I am trying to complete a paper in latex downloaded from an online template.
there shows an error while compiling:
This is BibTeX, Version 0.99d (MiKTeX 21.6)
The top-level auxiliary file: Islam2021.aux
I couldn't open style file IEEEbib.bst
---line 69 of file Islam2021.aux
: \bibstyle{IEEEbib
: }
I'm skipping whatever remains of this command
I found no style file---while reading file Islam2021.aux
(There were 2 error messages)
Process exited with error(s)
How can I fix this?
IEEEbib.bst is not a default style include in tex distributions. Either you can download it from wherever you have your online template from or you could try your luck with a random version of the file from somewhere on the internet, e.g.
https://2021.ieeeicassp.org/Papers/PaperFormat/IEEEbib.bst
(this might be a different version and might give different results ...)
I have a similar issue;
I copied and edited filetype_extensions.conf in my ~/.config/geany adding:
CALIBRE=*.rul;*.svrf;*.SVRF;*.cal;
Then under ~/.config/geany/filedefs I created following files:
filetypes.CALIBRE.conf ==> my custom filetypes
filetypes.commmon ==> I wanted specific colored named_styles
# For complete documentation of this file, please see Geany's main documentation
[styling]
comment=svrf_comment
key=svrf_keyword_comment,bold
[settings]
# default extension used when saving files
extension=svrf
lexer_filetype=NONE
[keywords]
# all items must be in one line
svrf=EXT ENC INT EXPAND
# the following characters are these which a "word" can contains, see documentation
#wordchars=_abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
# single comments, like / in this file
comment_single=//
# multiline comments
#comment_open=/*
#comment_close=*/
# set to false if a comment character/string should start at column 0 of a line, true uses any
# indentation of the line, e.g. setting to true causes the following on pressing CTRL+d
#command_example();
# setting to false would generate this
# command_example();
# This setting works only for single line comments
comment_use_indent=true
# context action command (please see Geany's main documentation for details)
context_action_cmd=
[indentation]
#width=4
# 0 is spaces, 1 is tabs, 2 is tab & spaces
#type=1
[build-menu]
# %f will be replaced by the complete filename
# %e will be replaced by the filename without extension
# (use only one of it at one time)
#FT_02_LB=_Lint
#FT_02_CM=jshint "%f"
#FT_02_WD=
#error_regex=([^:]+): line ([0-9]+), col ([0-9]+)
However when I open an svrf file type my custom filetypes is not recognized (no specific color while I chose some styling).
If I choose [styling=C] and lexer_filetype=C I am getting color for "C" code...
I also tried [styling] and lexer_filtype=NONE, but once again my custom highlight is not recognized.
I alread ready geany manual, as well as looked as some post but none of them is completely answering this subject (on the 2nd overflow link user has mapped to existing filetype hence he's not getting behavior he had wished).
geany custom filetype .sass for syntax highlighting
Geany: Syntax highlighting for custom filetype for SOME words
Do you have any idea on how to solve this issue?
I'm trying to insert a background image with the beamer package using the following:
\usebackgroundtemplate{%
\includegraphics[width=\paperwidth,keepaspectratio]{/path/to_file/background.png}%
}
The problem I'm having is that my background file path has an underscore in it, as I put in the example above. (This is my home directory on OS X, so I can't really change it.) When I generate this via pandoc the resultant latex file has the underscore escaped with a \, so it looks like this:
\usebackgroundtemplate{%
\includegraphics[width=\paperwidth,keepaspectratio]{/path/to\_file/background.png}%
}
but this makes it impossible for includegraphics to find the file and so it fails at that point.
If I manually remove the \ from the latex, or move the file to, say, the root directory, so that there is no underscore in the path, all is well. Here's the exact error:
LaTeX Warning: File `/Users/my\_name/Downloads/background.png' not fou
nd on input line 102.
! Package pdftex.def Error: File `/Users/my\T1\textunderscorename/Down
loads/background.png' not found: using draft setting.
So is there something I can do to tell includegraphics that the name is escaped, or to remove the escaping?
Here's the YAML:
---
name: John Doe
backgroundImage: /Users/my_name/Downloads/background.png
---
Text to add to template:
$if(backgroundImage)$
\usebackgroundtemplate{%
\includegraphics[width=\paperwidth]{$backgroundImage$}%
}
YAML values are interpreted as Markdown, unless specified otherwise. The backgroundImage is hence translated into LaTeX when used within $backgroundImage$.
The solution is to force literal interpretation of the input by telling pandoc that you know what you are doing, and that the input is already formatted as LaTeX:
---
name: John Doe
backgroundImage: '`/Users/my_name/Downloads/background.png`{=latex}'
---
This is based on the raw attribute extension, which is enabled by default for pandoc flavored Markdown.
I am printing an EPS File generated with following credentials.
%-12345X#PJL JOB
#PJL ENTER LANGUAGE = POSTSCRIPT
%!PS-Adobe-3.0
%%Title: InvoiceDetail_combine
%%Creator: PScript5.dll Version 5.2.2
%%CreationDate: 10/7/2011 4:46:59
%%For: Administrator
%%BoundingBox: (atend)
%%Pages: (atend)
%%Orientation: Portrait
%%PageOrder: Special
%%DocumentNeededResources: (atend)
%%DocumentSuppliedResources: (atend)
%%DocumentData: Clean7Bit
%%TargetDevice: (HP Color LaserJet 4500) (2014.200) 0
%%LanguageLevel: 2
%%EndComments
While doing Selection Printing on Ricoh Afficio 2090 or any other drivers/printers get the following error printed on the sheets
ERROR: undefined
OFFENDING COMMAND: F4S47
Stack:
.
Kindly Review and suggest a turn around for the same as i am already stuck in this hell. I have tried to convert/extract in PS but all in vain. I am using gsview to Print and view these files.
This is the problem:
%%PageOrder: Special
A ps document with "Special" page order can NOT be re-ordered. You cannot do a selection or range with this file because it is broken for this use. You must reprocess the file using Distiller or ghostscript (ps2ps or ps2pdf) in order to print selected or re-ordered pages from the document.
You can avoid this by generating your postscript files with a real Postscript™ driver (one not created by Microsoft).
The GSView Documentation has more about this.
Previously:
This line ...
%%TargetDevice: (HP Color LaserJet 4500) (2014.200) 0
... tells us that the file was generated with HP printers as a target. So this really is not an EPS file. Because it's not Encapsulatable. To generate output on a printer the file has to execute the showpage operator, which is a no-no for EPS files.
So uncheck the EPS box (it's a big fat lie, anyway), and select (install) a Generic Postscript driver. If you need to send it to multiple makes of printer, the file needs to make as few assumptions about the printer as possible.
The first thing is that this is not a valid EPS file, as it has PJL attached at the front. Many PostScript printers will strip this off, but by no means all.
This probably is not the source of the problem.
There is no way to 'review' the problem as you have not supplied the complete PostScript program. Without that there is no way to tell what is actually wrong, the error message tells you that the interpreter encountered 'F4547' while trying to parse a token, and that this has not been defined as a routine.
Most likely the file is corrupt, either damaged in some way, or possibly it is a biinary file and has been transmitted by some process which does has done some kind of conversion (CR/LF is common). The offending command looks like its ASCIIHex encoded, so that may be a red herring.
If you want additional help, you are going to have to make the whole program available somewhere.
I have a relatively complicated suite of OMake files designed for cross-compiling on a specific platform. My source is in C++.
I'm building from Windows and I need to pass to the compiler include directories which have spaces in their names. The way that the includes string which is inserted in the command line to compile files is created is by the line:
public.PREFIXED_INCLUDES = $`(addprefix $(INCLUDES_OPT), $(set $(absname $(INCLUDES))))
At some other point in the OMake files I have a line like:
INCLUDES += $(dir "$(LIBRARY_LOCATION)/Path with spaces/include")
In the middle of the command line this expands to:
-IC:\Library location with spaces\Path with spaces\include
I want it to expand to:
-I"C:\Library location with spaces\Path with spaces\include"
I don't want to change anything but the "INCLUDES += ..." line if possible, although modifying something else in that file is also fine. I don't want to have to do something like change the definition of PREFIXED_INCLUDES, as that's in a suite of OMake files which are part of an SDK which may change beneath me. Is this possible? If so, how can I do it? If not, in what ways can I make sure that includes with spaces in them are quoted by modifying little makefile code (hopefully one line)?
The standard library function quote adds escaped quotes around its argument, so it should do the job:
INCLUDES += $(quote $(dir "$(LIBRARY_LOCATION)/Path with spaces/include"))
If needed, see quote in Omake manual.
In case someone else is having the same problem, I thought I'd share the solution I eventually went with, having never figured out how to surround with quotes. Instead of putting quotes around a name with spaces in it I ended up converting the path to the short (8.3) version. I did this via a a simple JScript file called shorten.js and a one line OMake function.
The script:
// Get Access to the file system.
var FileSystemObject = WScript.CreateObject("Scripting.FileSystemObject");
// Get the short path.
var shortPath = FileSystemObject.GetFolder(WScript.Arguments(0)).ShortPath;
// Output short path.
WScript.StdOut.Write(shortPath);
The function:
ShortDirectoryPath(longPath) =
return $(dir $(shell cscript /Nologo $(dir ./tools/shorten.js) "$(absname $(longPath))"))
So now I just use a line like the following for includes:
INCLUDES += $(ShortDirectoryPath $(dir "$(LIBRARY_LOCATION)/Path with spaces/include"))