I tried opening Tools-> configuration file -> snippets.conf
and edited [c++] block
#~ [C++]
#~ cout=cout<<%cursor%<<endl;
#~ if=if (%cursor%)%block_cursor%
#~ else=else%block_cursor%
#~ for=for (int i = 0; i < %cursor%; i++)%brace_open%\n%brace_close%
#~ while=while (%cursor%)%block_cursor%
#~ do=do\n{\n\t%cursor%\n} while (%cursor%)\n
#~ switch=switch (%cursor%)%brace_open%case %cursor%:\n\t\t%cursor%\n\t\tbreak;\n\tdefault:\n\t\t%cursor%\n%brace_close%
#~ try=try%block%\ncatch (%cursor%)%block_curso
I added line#~ cout=cout<<(cursor%)<<endl;
then restarted my computer and geany multiple times it neither gave me error nor gave extension in FileName.cpp . When i type cout it gave normal tab not extension i added.
After fiddling with snippet.conf for a half hour or so, I stumbled on the rather annoying answer...
The # characters at the beginning of lines in snippet.conf are comment characters, and the ~ characters are apparently just there to confuse everybody. So for a snippet to work, both the section heading (e.g. [C++]) and the snippet definition should be flush left without the leading #~. Leading spaces work, but in that case syntax highlighting of the line in snippet.conf won't be shown, so it's best to just make things flush left.
Also, after adding a new snippet, there's no need to restart either your computer, geany, or even the document you want to use it in. A new snippet should be available as soon as snippet.conf is saved.
And what about all of the commented-out lines in snippet.conf? They apparently don't do anything as they are. However, they can be used to override geany's default snippet functionality by removing the #~ characters from the appropriate section heading and snippet lines and then making changes as needed.
Related
Cobol Reference Manual (6.3), on page 526, affirms literally:
Comment lines, inline comments, or blank lines in pseudo-text-2 or partial-word-2 are copied into the resultant program unchanged whenever pseudo-text-2 or partial-word-2 is placed into the source text as a result of text replacement.
Is it possible to have an example of how to build such a pseudo-text?
Thank you.
Livio Felicella
COPY MYLIB REPLACING ==some words== by ==
* comment line
* after an empty line
DISPLAY 'DONE'. *> with inline comment
==.
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?
What I am doing:
I am using the gmail gem in a Rails 4 app to get email attachments from a specific account at regular intervals. Here is an extract from the core part (here for simplicity only considering the first email and its first attachment):
require 'gmail'
Gmail.connect(#user_email,#user_password) do |gmail|
if gmail.logged_in?
emails = gmail.inbox.emails(:from => #sender_email)
email = emails[0]
attachment = email.message.attachments[0]
File.open("~/temp.csv", 'w') do |file|
file.write(
StringIO.new(attachment.decoded.to_s[2..-2].force_encoding("ISO-8859-15").encode!('UTF-8')).read
)
end
end
end
The encoding of the attached file can vary. The particular one that I am currently having issues with is in Finnish. It contains Finnish characters and a superscripted 3 character.
This is what I expect to get when I run the above code. (This is what I get when I download the attachment manually through gmail user interface):
What the problem is:
However, I am getting the following odd results.
From cat temp.csv (Looks good to me):
With nano temp.csv (Here I have no idea what I am looking at):
This is what temp.csv looks like opened in Sublime Text (directly via winscp). First line and small parts look ok but then Chinese/Japanese characters:
This is what temp.csv looks like in Notepad (after download via winscp). Looks ok except a blank space has been inserted between each character and the new lines seems to be missing:
What I have tried:
I have without success tried:
.force_encoding(...) with all the different "ISO-8859-x" character sets
putting the force_encoding("ISO-8859-15").encode!('UTF-8') outside the .read (works but doesn't solve the problem)
encode to UTF-8 without first forcing another encoding but this leads to Encoding::UndefinedConversionError: "\xC4" from ASCII-8BIT to UTF-8
writing as binary with 'wb' and 'w+b' in the File.open() (which oddly doesn't seem to make a difference to the outcome).
searching stackoverflow and the web for other ideas.
Any ideas would be much appreciated!
Not beautiful, but it will work for me now.
After re-encoding, I convert the string to a char array, then remove the chars I do not want and then join the remaining array elements to form a string.
decoded_att = attachment.decoded
data = decoded_att.encode("UTF-8", "ISO-8859-1", invalid: :replace, undef: :replace).gsub("\r\n", "\n")
data_as_array = data.chars
data_as_array = data_as_array.delete_if {|i| i == "\u0000" || i == "ÿ" || i == "þ"}
data = data_as_array.join('').to_s
File.write("~/temp.csv", data.to_s)
This will work for me now. However, I have no idea how these characters have ended up in the attachment ("ÿ" and "þ" in the start of the document and "\u0000" between all remaining characters).
It seems like you need to do attachment.body.decoded instead of attachment.decoded
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"))
I am trying to implement this new environment in LaTeX:
\newenvironment{javacode}[2]
{\begin{lstlisting}[language=java, label=#1, caption=#2]}
{\end{lstlisting}}
And then use it like such:
\begin{javacode}{c}{some code}
int x = 5;
\end{javacode}
But I am getting the following error:
Overfull \hbox (6.0pt too wide) in paragraph at lines 6--6
[][][][][][][]
[1] [2]) [3])
*
Can anyone help as regards fixing this problem?
[Update]
I tried it doing it like Red-nosed unicorn instructed, and it worked correctly.
But now I tried adding a \begin{singlespace} like such:
\lstnewenvironment{javacode}[2]
{
\begin{singlespace}
\lstset{language=java, label=#1, caption=#2}}
{
\end{singlespace}
}
And I got the same error:
Overfull \hbox (6.0pt too wide) in paragraph at lines 6--6
[][][][][][][]
[1]) [2] [3])
*
This is a special case because the listings environment needs to parse ahead itself to find the end of itself. The reason is that macros inside the listings environment must not get expanded – that of course includes the end tag of the environment.
So basically it looks in each line if the line contains \end{lstlisting} – but in your case, no such line exists since the \end{javacode} macro has not yet been expanded. So listings continues to search until the end of the file.
Listings defines an own command to work around this. From the documentation:
\lstnewenvironment
{⟨name⟩}[⟨number⟩][⟨opt. default arg.⟩]
{⟨starting code⟩}
{⟨ending code⟩}
For example:
\lstnewenvironment{javacode}[2]
{\lstset{language=java, label=#1, caption=#2}}
{}
EDIT In response to your edited question: I tried to compile the following minimal “working” example. Actually, it’s not so much working – the latex processor just stops right in the middle and waits for a user input.
Since the listings documentation makes no mention of a special treatment of singlespace, I think you may have uncovered a bug. The best course of action is probably to get feedback from the maintainer of the listings package.
% mini.dvi
\documentclass{article}
\usepackage{listings}
\usepackage{setspace}
\doublespacing
\lstnewenvironment{javacode}
{\begin{singlespace}
\lstset{language=java}}
{\end{singlespace}}
\begin{document}
\begin{javacode}
int a = 1;
int b = 2;
\end{javacode}
\end{document}
Upon further research, I found this http://www.tug.org/pipermail/texhax/2009-June/012699.html
To workaround my solution, I need to use \singlespacing instead of the singlespace environment.
The following is now my working code:
\lstnewenvironment{javacode}[2]
{\singlespacing\lstset{language=java, label=#1, caption=#2}}
{}