I am using Scribble to write assignments and would like to have the ability to include common text snippets somewhere in the document. For example:
#lang scribble/manual
#section{Some section}
#include-file["common-pretext.scrbl"] #; my imaginary command
Some additional text after the pretext
#section{Next section}
More text...
I would like #include-file to include the contents of common-pretext.scrbl just as if I had copy/pasted its contents at the specified position. That is, I would like its contents to be part of Some section and also properly handle Scribble commands occurring in common-pretext.scrbl.
I know that Scribble has #include-section, which is similar to what I want. However, #include-section always starts a new section and text following it until the next section is silently dropped (I am not sure why this happens, but presumably because of how the document is constructed). I also tried Racket's #include, but then the contents are not shown at all. Lastly, I tried building a macro that does what I want, but failed to make it work (if a macro is the way to go, then I am happy to share my attempts so far).
Is there such a command already and if not how can I build one?
This question is pretty old, but if you are still looking, this package does what you want:
https://docs.racket-lang.org/scribble-include-text/index.html
Related
I've got a rather big and verbose section of line-based configuration file. I'd like to use this section as template (assuming I going to preconfigure this section, test it and then replace actual values with $(make) $(macros)), substituting the key parameters (very few of them, really) effectively "cloning" this "template" with few customized parameters to the working config file. Can make do the work for me in the described case?
Please bear with me, I'm truly a make layman and even not sure if it is right tool in this case.
An example
I'm preconfiguring and testing something like:
<section0>
contains a lot of settings
which were tested and should
be exactly the same in every copy
except marked with trailing0
</section0>
I'm wondering that if convert tokens marked with trailing zero above to macros:
<$(section)>
contains a lot of settings
which were tested and should
be exactly the same in every copy
except marked with $(trailing)
</$(section)>
... wondering that I can utilize make to produce clones of premade configuration slightly customized with my data in place of macros:
<section42>
contains a lot of settings
which were tested and should
be exactly the same in every copy
except marked with trailing42
</section42>
<foo>
contains a lot of settings
which were tested and should
be exactly the same in every copy
except marked with bar
</foo>
Assuming "section42", "foo" and "trailing42", "bar" are substitutes for $(section), $(trailing) macros respectively.
You can use m4 preprocessor in your makefiles to do exactly that: expand macros in template files:
M4 can be called a “template language”, a “macro language” or a “preprocessor language”. The name “m4” also refers to the program which processes texts in this language: this “preprocessor” or “macro processor” takes as input an m4 template and sends this to the output, after acting on any embedded directives, called macros.
Create a file named section.m4:
$ cat section.m4
<section0>
contains a lot of settings
which were tested and should
be exactly the same in every copy
except marked with trailing0
</section0>
And have a rule in your makefile to expand macros in that template to produce section.cfg:
section.cfg : section.m4
m4 -Dsection0=foo -Dtrailing0=bar $< >$#
I'd like to have links with the syntax [[foo bar]] go to files with the name foo bar.org. This would make using org-mode much more like using a personal local wiki.
Is this possible without breaking existing link functionality? I'd also ideally still be able to export to html, etc. with standard org-mode tools.
The best I've been able to do is something like: (setq org-link-abbrev-alist '(("o" . "file:%s.org")))
This lets me use the syntax [[o:foo bar]], but that is more verbose, and looks distractingly ugly inline. For example: The quick brown o:fox jumps over the o:lazy_dog. And [[o:foo bar][foo bar]] is even more verbose to type and edit (though it reads fine in org mode).
I don't have a ready made solution and am not a programmer, but this part is self-documenting in org.el, you can write a dedicated link search function. I cite:
"List of functions to execute a file search triggered by a link.
Functions added to this hook must accept a single argument, the search
string that was part of the file link, the part after the double
colon. The function must first check if it would like to handle this
search, for example by checking the `major-mode' or the file
extension. If it decides not to handle this search, it should just
return nil to give other functions a chance. If it does handle the
search, it must return a non-nil value to keep other functions from
trying.
Each function can access the current prefix argument through the
variable `current-prefix-arg'. Note that a single prefix is used to
force opening a link in Emacs, so it may be good to only use a numeric
or double prefix to guide the search function.
In case this is needed, a function in this hook can also restore the
window configuration before `org-open-at-point' was called using:
(set-window-configuration org-window-config-before-follow-link)")
See also Hyperlinks :: Custom Searches # gnu.org
It seems this forum is more alive than mailing list : http://sourceforge.net/mailarchive/forum.php?forum_name=cedet-semantic.
I would like repost my quest from a week ago from there:
First hi to all who contribute to this great package as CEDET :D .
Without much hussle I am able to get working most of the CEDET futures, but when it comes to senator / semantic things get more tought :\ .
Parsing local files are fine.
I don't use EDE not to get things more complicated.
I use the 1.0.6 git trunk version, for compability with ECB.
First is the rumble about the emacs core / cedet git-trunk hussle. How do I check that current installation is running the latter ? ( I have done some .emacs modificaitons see below) .
I generally cannot get the proper autocomplete working for external libs - in this case the OGRE3D project, which all are in the /usr/include/OGRE. I suppose I have added to 'search path' include properly, semantic-describe-c-env. sees them added properly.
2.a What are the basic commands to the semantic parser ? , that is I need to force it to parse the desired includes.
Once I saw semantic parsing the OGRE files in the 'idle time'. Still the autocomplete does not work ( OGRE:RAY is not recongized as a type).
senator-completition-menu-pop gives some non-matching 'c**p'
2.b I know there are customize-group options for semantic, tough their description say little to me.
From the other post:
"Yes, there is a setup cost. You can use semanticdb.sh to pre-parse your
code, but if you never open every file, you might end up with Emacs
having such a huge data structure it gets larger that your machine can
handle. If your project is small, this shouldn't be a problem."
Well this might be, if that would parse OGRE.
here's my .emacs:
.emacs at pastebin.com
Here's what I got on the mailing list, hope that it would help someone , thaks to Eric Ludlam :D :
======================
1. First is the rumble about the emacs core / cedet git-trunk hussle. How do I check that current installation is running the latter ? ( I have done some .emacs modificaitons see below) .
After emacs start, use:
M-x cedet-version RET
and look for the 1.1 version from CEDET/bzr.
I just tried this and noticed not everything has the right version
number. Interesting. I'll have to look into that.
Anyway, the next thing to try is:
M-x locate-library RET cedet RET
and make sure it points where you think it should.
2. I generally cannot get the proper autocomplete working for external libs - in this case the OGRE3D project, which all are in the /usr/include/OGRE. I suppose I have added to 'search path' include properly, semantic-describe-c-env. sees them added properly.
If you enable global-semantic-decoration-mode you can right-click on
header files, and it will give you some options, such as showing where
it things the header is, and showing if it has been parsed yet or not.
2.a What are the basic commands to the semantic parser ? , that is I need to force it to parse the desired includes.
You can use the include menu to force a header to be parsed, or visit
said include. If it can't find it, you can add OGRE to your path from
there too.
If you vist your header, you can use the senator menu to force a file to
reparse, or use:
C-u M-x bovinate RET
to do it.
Once I saw semantic parsing the OGRE files in the 'idle time'. Still the autocomplete does not work ( OGRE:RAY is not recongized as a type). senator-completition-menu-pop gives some non-matching 'c**p'
Autocomplete can fail for many reasons. The best way to find out why is:
M-x semantic-analyze-debug-assist RET
at a place you want to do completion. It will tell you about your
header files, symbols, and the like. It could be your preprocessor
symbols need some setup.
For large complex library headers, sometimes it is just a matter of
having the right pre-processor symbols setup in Semantic so that the
right bits of the headers get parsed for symbols. You'd have to visit a
header where a symbol you want to complete is, and see if it was parsed.
Using:
M-x boviante RET
will dump the symbol table.
2.b I know there are customize-group options for semantic, tough their description say little to me.
From the other post:
"Yes, there is a setup cost. You can use semanticdb.sh to pre-parse your code, but if you never open *every* file, you might end up with Emacs having such a huge data structure it gets larger that your machine can handle. If your project is small, this shouldn't be a problem." Well this might be, if that would parse OGRE.
I doubt parsing the includes is the problem here. I think there is just
something new in the ogre headers we'll have to deal with.
Eric
===================================
I want better control of the footnote positioning within an email message. I could write the code to modify footnote-mode to do what I want, but first I want to see if somebody else has already solved this problem.
When I am top-posting with message-mode and add an entry with footnote-mode the footnotes go to the end of the buffer, but instead I want it to come before the previous message citation which starts out with something like:
Elvis Presley <the.king#graceland.com> writes:
If I have a signature automatically added based on footnote-signature-separator then the footnotes get positioned before the signature, however in email I don't use a signature. And furthermore, when I use a closing like:
-Elvis
or
Thanks,
Elvis
then I usually want to footnotes to come after that closing.
What I would like is to have the best optimal position detected automatically whether I am top-posting or in-line posting. I expect the best solution will be to use text-properties-at to detect gnus-cite-* lines and maybe to define text properties for the footnotes section. And/or maybe overlays?
Also note that suggestions like the following will not work:
(setq footnote-signature-separator "^-- $\\|#.*writes:")
Not only is that overly simplistic for the kind of positioning control I would like, but it also simply does not work correctly.
I want to fully-justify latex code on EMACS so that my latex code will look better. For example, I remember my advisor sending me latex in fully justified way like this:
In ~\cite{Hummel2004}, authors described an approach for harvesting
software components from the Web. The basic idea is to use the Web as
the underlying repository, and to utilize standard search engines,
such as Google, as the means of discovering appropriate software
assets. Other researchers have crawled through Internet publicly
available CVS repositories to build their own source code search
engines (e.g., SPARS-J)~\cite{Matsushita2005}.
I suppose that his column-width is set to 70 columns.
Could someone give me a hint?
The standard fill.el package includes the command justify-current-line which is part of what you need. From the function help:
Do some kind of justification on this line.
Normally does full justification: adds spaces to the line to make it end at
the column given by `current-fill-column'.
Optional first argument how specifies alternate type of justification:
it can be `left', `right', `full', `center', or `none'.
If how is t, will justify however the `current-justification' function says to
And other posters have already given you the magicall invokation:
M-x set-justification
As a philosophical side note, the point of fixed-wdith text justification is to fake real typography on a inflexible output device. So applying it to LaTeX source seems a little odd to me. Moreover, I have been using the "one sentence to a line" approach to LaTeX documents for some months now, and find that it really does improves both the editability and the source-control behavior of LaTeX, so I would recommend against doing this.
If you select the region, and then press Ctrl-u M-x fill-region you get "full justification".
M-x set-justification-full
Use Refill mode afterwards to not have to run the command again after typing.
To get line wrap in the file itself (as opposed to something like longlines-mode that does not alter the structure of the file), I use auto-fill-mode, which automatically applies M-q (fill-paragraph) to each paragraph. For example, I use auto-fill-mode in mail-mode. You could do something similar with your LaTeX mode with a hook like this:
(add-hook 'TeX-mode-hook 'turn-on-auto-fill)
Assuming your TeX mode's hook is TeX-mode-hook.