I am using Emacs 23. This comes with OS and I can not change it for some reasons.
Few files I open have long pathnames which are eating all the space and I can not see enabled modes or current line/column. Is there any way to make the mode line multi-line OR some other solution?
Thanks
Perhaps SmartModeLine would help:
Fixed width (if you want): Lets you set a maxium width for the path
name and mode names, and truncates them intelligently
Here is a less complex solution, which may be a little easier for you to modify to suit your own -- it uses a simple function called shorten-directory:
http://amitp.blogspot.com/2011/08/emacs-custom-mode-line.html
Related
I have helm-find-files bound to C-x C-f since it provides a much more convenient way to open files. Unfortunately for me, if point is currently inside something that looks like a filename then that alters helm-find-files's behaviour, often changing its current directory. (See https://github.com/emacs-helm/helm/issues/1178 )
Is there a straightforward way for me to nobble thing-at-point inside helm-find-files-initial-input so that it never believes point is inside a filename? I thought that defadvice would help but I'm having trouble working out how.
Or perhaps there's a better way to make helm-find-files behave consistently no matter where point is without modifying its implementation directly?
You can set helm-find-file-ignore-thing-at-point to t.
Documentation:
Use only ‘default-directory’ as default input in ‘helm-find-files’.
I.e text under cursor in ‘current-buffer’ is ignored.
Note that when non-nil you will be unable to complete filename at point
in ‘current-buffer’.
The echoing is very slow.
Would it be good for emacs to truncate strings greater than certain number of chars?
How could I do this?
The culprit is comint-mode, where the (I)Python shell is built upon. For these cases of very large output python-mode.el offers a way to avoid comint-mode, see py-fast-process-p.
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.
In noweb mode, I would like to make the doc chunks and code chunks easier to distinguish. I'm already using font-lock-mode, but it applies the same face to strings in R and strings in tex, so doesn't distinguish the code and doc chunks very well.
For example, a slightly different background color for the code chunks.
One possibility would be to define a new face for the minor mode of the code chunk, but then that face would also apply when editing a buffer in that mode.
Another possibility would be to create an overlay for the code chunks.
Also, somewhat related, org-mode can be configured to use different background colors for source blocks.
Update: I now use polymode to achive this.
You can use noweb-font-lock-mode from ESS to get syntax highlighting for both code and documentation chunks. I'd recommend you also use noweb-mode from ESS too, because it has some improvements.
One option would be mmm-mode, with which you can define regions that are in a different mode -- it also applies a face to the entire sub-mode region, which you can use to easily distinguish those regions within the parent file.
I personally use this for Ruby within IRB, Javascript and CSS within HTML etc. There's an example for javascript in my emacs config.
The MuMaMo extensions allows different rules for different parts of the file. Getting the nXhtml package will give you the mode and I think you can configure it to do what you want.
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.