Disabling thing-at-point inside helm-ff-guess-ffap-filenames - emacs

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’.

Related

Portacle Lisp : Slime-repl-sbcl prompt keep auto-scrolling back

as the title said, I am learning common lisp right now and using portacle, following Practical Common Lisp by Peter Seibel.
I found it quite annoying that the Slime-repl-sbcl buffer keep the writing at the end of the screen (using C-l or C-v doesn't help since once I try to execute an expression it will roll back to the end of the screen)
Is there anywhere to improve this? (should I just write on a text file and compile it? the only similar subject I found was about Cider repl and couldn't understand it, since I am still new to lisp)
Thank you for your time
I would like this fixed too. No solution yet. In slime-repl.el, I found:
scroll-conservatively (variable):
A value of zero means always recenter point if it moves off screen.
my test wasn't conclusive.
slime-display-output-buffer (function), which calls slime-repl-show-maximum-output, which role is to
Put the end of the buffer at the bottom of the window.
I rewrote slime-display-output-buffer without this call, but that wasn't conclusive either.
Maybe I tested badly.
(I'm making this answer a wiki)
You would indeed typically write in a source file, and compile each expression separately. Use the REPL only to test functions or do simple computations. To compile functions (or really, any toplevel expression), use C-c C-c - bound to slime-compile-defun by default - when the point (= your cursor) is inside the function's code. The REPL will then "know" of it, so you can test it there, but as it is now written in file, you can also modify it without having to copy/paste anything ! Just make sure to recompile functions that you modify !
If you want to compile/load entire files at once, look at the other compilation commands, e.g. slime-compile-and-load-file (see the SLIME manual, and its Compilation section)
For your problem: there is Emacs variable, named comint-scroll-to-bottom-on-input (or something along those lines, can't remember exactly ...) which enables the behaviour you are seeing, so that you don't have to scroll back to enter new expressions. It is possible that SLIME has another variable which configuring this behaviour for its REPL; in that case, it would probably be named almost the same, and you can set it to nil to disable it.
Finally, don't hesitate to look at the other tools provided by SLIME ! For example, it comes with an "inspector" (see the relevant section), that you can use instead of evaluating expressions such as *db* in the REPL. In that simple case, it makes no real difference, but if you start having - say - hash-tables or different structures/classes, it becomes an incredible tool for interactive development, to examine the internal of almost everything, redefine things directly from within the inspector without needing complex accessors, and so on.

what is difference between before-save-hook and write-file-functions

I read the manual at http://www.gnu.org/software/emacs/manual/html_node/elisp/Saving-Buffers.html#Saving-Buffers, but still not quite understand what is the difference between the two. It seems to me they both work as a hook to run whatever function you set before saving the buffer to the visited file. could anyone explain with examples? Thanks.
write-file-functions can be used to simply do arbitrary things before saving the file, but its stated purpose is to allow some non-default function to actually do the work of saving the file (or perhaps to manipulate the content for the purposes more directly related to the saving mechanism itself).
If modifying the mechanism for saving a file is not what you wish to do, I strongly suspect you should be using before-save-hook.
See also C-hig (elisp) Saving Buffers RET
write-*-functions provide a strict superset of what before-save-hook can do. More specifically, write-*-functions can replace the normal saving mechanism with another one. This means that a function added to write-*-functions might end up unused because some earlier function has already saved the buffer.
Well I would say that before-save-hook is here to modify the content. While write-*-functions are in charge of coding systems (compress the file content for instance or following any other file format) and the backup files.
Moreover write-*-functions may be buffer local while it does not seem to be the case for before-save-hook. But then I am not sure to know what it implies.

Getting Emacs to recognise custom math delimiters so it can colour the face accordingly

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.

Contextual help in Emacs?

I am not a very good at using Emacs, but the feature I would like the most would be some integration with help/documentation for a particular language/API I use at the moment. I would imagine that there would be help displayed in another buffer depending on where I put my cursor while editing.
I wonder if there is a package that does that, even if it would be very simple, just displaying some file based on the keyword. I think there is, but I cannot find it ("help" is a too generic word).
(In particular, I would like to have this help for Common Lisp, but other languages, such as Java or C, could be useful.)
ILISP and SLIME provide several methods for looking up a function; see the Emacs wiki and the SLIME documentation. Or just built into Emacs itself, there are functions like C-h f to get function help or M-x man; both use the text at the point by default. You could pretty easily adapt them to work for another language of your choice.
Assuming you are using SLIME for common-lisp, you can take a look at slime-autodoc-mode.
Sorry, can't help with a generic solution for this.
You can set up the CLHS root for SLIME in your .emacs file:
(setq common-lisp-hyperspec-root "/usr/share/doc/hyperspec/HyperSpec/")
Adjust the path to where you put your HyperSpec.
Then, C-c C-d h with point at a symbol will look it up there in your browser.
One thing you might like to enable is eldoc-mode, by adding (turn-on-eldoc-mode) to your mode hook functions for the appropriate programming modes.
In ElDoc mode, the echo area displays information about a
function or variable in the text where point is. If point is
on a documented variable, it displays the first line of that
variable's doc string. Otherwise it displays the argument list
of the function called in the expression point is on.
This is probably less than you were after, but it still makes a good companion to a fuller-featured contextual help system, and there are a number of programming modes that support it.

why shouldn't I use a push-mark

I implemented a small function, which parses an SQL INSERT statement and highlights a column value when a cursor is on a column name and vice versa.
Then I wanted to add a possibility to quickly jump between column name and column value. I used push-mark in my implementation, so I can jump with C-x C-x (exchange-point-and-mark). It works too, the only thing which bothers me is a elisp doc, which says
Novice Emacs Lisp programmers often
try to use the mark for the wrong
purposes. The mark saves a location
for the user's convenience. Most
editing commands should not alter the
mark.
My usage of mark - is it correct? Or what would be a better solution?
Consider an analogy with the position of point: the user only wants point to move when they issue a point-moving command. It would be exceedingly annoying if random operations like font-locking moved the point. Hence the recommendation to wrap function bodies in (save-excursion ...).
If your function sets the mark explicitly for the user, that's fine. (In this case I suggest calling your function something like sql-mark-column-value to make it clear that setting the mark is one of the things it does.) The point of the documentation you quoted is that commands should not set the mark incidentally as a result of doing something else.
If your function just happens to set the mark when the user places point on a a column name in a SQL statement, that's probably not so convenient. Imagine a use case of someone trying to cut or copy a section of a SQL statement; every time they try to move point within the statement their mark gets clobbered! For this use case you probably want to provide a separate command like sql-goto-column-value instead of relying on exchange-point-and-mark.
Of course, if this is purely for your own use, anything goes.
AFAIK, this is the correct use of push-mark. I think the documentation discourages the use of push-mark instead of save-excursion for the purpose of saving the state of the buffer while performing certain operations.