I'm trying to edit documents (MultiMarkdown), that will do an auto-fill on paragraphs that are not indented 4 spaces, and will NOT do an auto-fill on paragraphs that ARE indented 4 spaces.
Where should I start to look to figure out how to code this?
You are going to need fill-paragraph, if, probably progn, probably string=, save-excursion, forward-paragraph, backward-paragraph and perhaps a few more. All of these can be read up if you do M-x describe-function and supply it the name.
As for the how, it is in your question. If the paragraph begins with 4 blank space letters, fill-paragraph.
Does that answer? Have I missed anything?
Where should I start to look to figure
out how to code this?
I think this is too general a question to answer. We don't know anything about your background in programming. Do you know Lisp? Do you know elisp? How well do you know Emacs? Do you know about advice? etc.
Programming in Emacs is well documented (introduction and reference). I suggest you start playing around with the fill- functions - when you run into more concrete problems with that, I'm sure it will be easier for people to help you out.
Related
Something that has always burned me up in programming, not just VB, is how inefficient it is to make multi-line comments. I'm not exactly a neat freak, but I do like comments to all be about the same length, around 80 characters including leading whitespace. But, to do this, I have to manually control how long the comments are. And the really frustrating part is when the change to only a few words requires an unreasonable amount of work.
I have found many questions on StackOverflow asking about multi-line commenting, but none to actually address this feature.
Wouldn't it make sense to have a commenting feature in VB, Eclipse, etc. to enter a a mini word processing mode mode that would low simple features like word wrap that would format the comment automatically? Is there one available that I'm just missing?
Or am I just being lazy? But, if it is a good idea, how can it be suggested to Microsoft, Eclipse.org, and others.
The only way to do multi-line comments in VB.NET is to do a lot of single line comments.
Really, the only option you have is the single tick (') in front of a line.
You can use Ctrl+K, Ctrl+C and Ctrl+K, Ctrl+U to comment or uncomment selected lines of text. In C# you can use /* ... */ to comment an entire block of code.
Look for more information on Custom Writing
When running emacs calc, typing a prefix key, say 'm', followed by '?' is supposed to show all mode-related commands in the minibuffer as a kind of quick help facility.
For several years I have noticed that this quit working for me. When I hit the '?' the minibuffer flashes the help for a small fraction of a second, then goes blank. I can sometimes see parts of the help text rendered but ususally it blanks too fast to see it.
This does not happen when I run emacs -Q to skip my init file, so it is something in the init file that is the cuplprit.
My init file is quite large. I would like to put something like '(exit)' in different places in my init file to stop processing the init file and see if I can pin down what is causing the problem.
(1) What is the right way to do this?
(2) Anybody else see this problem with the minibuffer in calc?
Good question. The answer is simple: recursively bisect your init file.
Do that by commenting out 1/2 of it, then 3/4, then 7/8,... This is a binary search, and it is very quick, even though it might not seem that way at first. It is systematic, and essentially blind (thoughtless).
To comment out a block of text, use command comment-region. To uncomment a block of text, use C-u with the same command.
Trust me - in no time at all, you will have identified the culprit code, no matter how big your init file is. And if you load other libraries from your init file, and doing the exercise above shows that the culprit code is in one of those libraries, then do the same thing with (a copy of) that library code: recursively bisect it.
After several hours of trying to narrow down the problem, I found the culprit.
When key-chord-mode is set on in calc, the key help facility displays the symptoms I mentioned above.
Would like to keep key-chord enabled globally and disable it in calc-mode, but turning it off in the calc-mode-hook turns it off for all modes. Any ideas?
Anyway, I am closer to figuring out this long-term irritant.
I have found a code to make typing equations in LaTeX in a simpler and faster way. Instead of typing
\begin{equation}
\end{equation}
I can now type
\be
\ee
It works great and I am happy with it. The code, found in this document (p. 13), is
\makeatletter
\newcommand{\be}{\begingroup
\setlength{\arraycolsep}{2pt}
\eqnarray%
\#ifstar{\nonumber}{}%
}
\newcommand{\ee}{\endeqnarray\endgroup}
\makeatother
My problem is that I use emacs, and it doesn't recognise those math delimiters and hence it doesn't give the face the proper math colour. I have tried to customise this by using the command M-x customize-apropos to try and find something I could use, but the closest I got were the variables
'font-latex-math-environments',
which I don't think is what I am
after since from what I can see I
can only type the name of the
command which goes inside the curly
brackets in \begin{} and \end{}
'font-latex-make-built-in-keywords',
which would require more knowledge
from me than I have, and I don't
even know whether it would work.
What I would like to know, thus, is how to set up Emacs so that whenever I used the pair \be and \ee it would give the face the same colour as I set up for math. I imagine this would require an emacs lisp code, which would be great so I could modify it to include other things if so I wished.
Can anyone help me getting this done?
This is not really an answer to your question, but if it's just about saving keystrokes for writing an equation environment, you might want to try the following.
From the tags under your question, I assume you're using AUCTeX mode. With that, instead of typing
\begin{equation}
\end{equation}
every time, use the following shortcut to have AUCTeX insert an environment interactively: C-c C-e. This will prompt your for the name of the environment ("equation") which you can type using tab-completion.
So you do save a couple of keystrokes, the result is syntactically correct, you don't need the additional \be and \ee commands, and what's best is that this approach is generic, i.e., it works for all LaTeX environments, not just equation.
When I use describe-function, I get the documentation text displayed in a Help buffer.
If the doc is long enough, it will wrap in the buffer, but it doesn't wrap nicely. like this:
I can make the docstring use 72-character lines, but that supposes that the window will be 80 characters, which is not always the case.
Is it possible to get describe-function to emit documentation in a more nicely formatted way?
Try enabling global-visual-line-mode to get nice text wrapping in all your buffers. It works in code and help buffers, but doesn't mess up your line numbering! Of all the line wrapping modes for emacs, I find it to be the best. If you don't want to use it globally, simply try M-x visual-line-mode.
No, please do not "try enabling global-visual-line-mode" as your solution for this.
Just try adopting the Emacs conventions for doc strings. See the Elisp manual, node Documentation Tips (aka "Tips for Documentation Strings").
In general, doc strings should not have lines wider than 60 chars.
Remember that there are multiple places where Emacs uses doc strings, including for apropos. Emacs expects doc strings to follow the documented conventions, for best results.
I use emacs to edit most of my answers for SO, and although I use longlines-mode (I have not upgraded to emacs 23 because of some critical bugs that don't look like being fixed any time soon), I can't find a way to get longlines-mode to respect the indentation used for Markdown. I would really like to fix this, but I want it for an ordinary buffer, not for org-mode (as already answered).
Does anybody have suggestions on how I can get longlines-mode to indent wrapped lines? I am definitely willing to try hacking the Emacs Lisp, although my Emacs Lisp is pretty rusty...
I just looked through the source code of longlines.el. There doesn't seem to be any hook there to have the wrapped lines indented. If you want to do this, you'll need to write a bit of elisp (and, more importantly, understand all of the functions for doing text-properties.)