Emacs/auctex not asking for prompting label anymore - emacs

I know that the default mode of Auctex is that prompting c-c c-e equation RET is supposed to ask me to prompt a label, unless I modify purposely the reftex-plug-into-AUCTeX value.
I find myself in a situation where, after installing the last version of aquamacs (on a new config), I am not asked anymore to prompt a label, which is assigned by default to some eq:N value.
I'd like to have this very convenient prompting feature back, any idea where I should look for ?

Related

Some shortcuts don't work on emacs beginning with C-c

In Haskell-mode, the shortcut C-c C-= is defined to do something.
Trying this shortcut, I realized that emacs do not recognize the shortcut C-c C-=.
Indeed, when I try the shortcut on emacs, the buffer write C-c = is not defined although I pressed C- C-=. I have the same problem with some other symbols like '.' or '§'. But shortcuts like C-c C-l or C-c C-c work.
I try to remove my .emacs but I have the same problem.
a friend have the same problem as me.
Both we are on ArchLinux (64 bits) and we use emacs in console. The keyboard is an azerty.
The problem come from emacs ? Arch Linux ?
Your terminal can't send Emacs C-= so you can't use that key sequence. (Emacs would recognise it if it received it, but that won't happen.)
Your options are:
Run GUI Emacs.
Use M-x name-of-command RET (for whatever command is bound to the key sequence you're not able to use). Use C-hm to see the major mode's bindings, or C-hb to see all current bindings, in order to learn what those command names are.
Create new custom keybindings for the commands in question (i.e. bindings which your terminal can send to Emacs).
Find a different terminal emulator with enhanced key sequence abilities. The vast majority of them will be no better than what you have, because they're all adhering to the limitations of the terminals they're emulating. The most capable one I know of is http://invisible-island.net/xterm/xterm.html but you may need to compile it yourself, and then expect to spend lots of time configuring it. (It's not a trivial solution, though, and xterm requires a GUI environment, so running GUI Emacs is much simpler.)
Use C-x#c<key> instead of C-<key>.
With that last option, you can use a sequence your terminal can send to fake a sequence that it can't send.
C-cC-= would become C-cC-x#c=
If you really wanted to use that last option, you can set a custom binding to simplify the sequence (may be necessary in some instances to avoid conflicting with existing sequences). See the end of https://stackoverflow.com/a/24804434/324105 for more information.
To add to phils' post - another option is an Emacs package (which I wrote), which can teach Emacs and terminals how to properly recognize all PC keyboard keys and modifier key combinations:
https://github.com/CyberShadow/term-keys
The default configuration already includes encoding key combinations like Ctrl=, as well as similar variations.

Shift selection in Emacs 24 does not highlight text

I must be stupid, but I just switched to Emacs 24, and holding Shift while moving the point no longer highlights text. Mouse selection works as before. What am I missing? Did I turn it off by chance? Or has Shift selection been deemed unergonomical so we have some other, better keyboard-based selection at hand?
Shift selection is enabled by default in Emacs 24.
You can always run emacs -Q to disable your init file and any other default libraries, in order to determine what Emacs' default behaviour is.
You can also run emacs -q which will disable only your init file (other system-wide init files can be loaded).
If the feature works without your init file and does not work with it, you can then start to narrow down what part of your init file is at fault (often by commenting out functionality until the feature starts working as expected -- note Drew's comment).
In this case I suggest that you firstly verify (using C-hv) that the shift-select-mode variable is non-nil (when running with your normal configuration), as a nil value means that shift selection is disabled.
I also found it useful to look at load-path variable, C-h v load-path, which directed me to the culprits, old elpa packages.

RET does not select the default in Command selection

When I use the Command in Auctex C-c C-c, it brings up a list of possible commands. It will usually select a reasonable default (e.g. Command: (default View)), however, when I press RET, it selects whatever is selected in the list below. I suspect this behavior is caused by one of the following packages I have installed
flx-ido
ido-ubiquitous
ido-vertical-mode
smex
To be honest, I used pieces from others' .emacs, so I'm not sure which of the customizations are causing this.
You do not have to deactivate it. You can type C-j to accept the current entry. If the current entry is empty, it will select the default.
It was ido-ubiquitous. Deactivating fixed it

Emacs locks hard over PuTTY when £ is entered

I'm using emacs (21.4.1) via PuTTY (0.60) connected to a CentOS5.3 box with a UK keyboard. Whenever I enter the £ symbol emacs locks hard, making the whole putty window unresponsive and loosing all changes.
Edit:
Futher to pajato0's suggestion, I get the following message:
à (translated from £) runs the command self-insert-command
which is an interactive built-in function in `C source code'.
which is an interactive built-in function in `C source code'.
It is bound to many ordinary text characters.
So it looks like I need to rebind the key. How would one do this?
To determine what role, if any, Emacs is playing in your scenario, I would suggest that you try C-h k # where # is your pound key. If it hangs, then Emacs is not getting the key at all and you have a Putty/Windows issue most likely. If Emacs tells you the function binding then you have some hope of fixing it by changing the key binding. My best guess is that Putty is capturing the key and sending it to Windows which is dropping the ball.
You could try another ssh client to see if it is putty-specific. I tend to just run
startxwin.sh # from a MinGW rxvt terminal
after which an xterm pops up in which I do
ssh -X some.unix.box # from the new xterm
after which I fire up a tabbed terminal emulator in which I keep several sessions 'forever'. And my US keyboard has no Pound sign so no way for me to test your issue...
I would look at the character set translation that putty is performing (window->translation in settings). It could be that the character code that is being sent for a pound symbol (don't have a UK keyboard...) locks up the terminal somehow, or that the character that is being returned in response to the keypress is causing some similar behavior (e.g. waiting for the completion of a code point).
You might want to try it with everything set to UTF-8 (charset/locale on linux side, and on Putty translation), to minimize the chances of confusion...
In response to your question "how does one rebind a key": use the define-key function, e.g.
(define-key global-map [S-Home] 'beginning-of-buffer)
The hard part is figuring out how to represent your key and then choosing a suitable function. For example, you might do something like:
(defun make-euro ()
"Euro")
(define-key global-map # 'make-euro)
But I would also suggest that you file a bug since if trying to self-insert your # key causes Emacs to hang, that is clearly Emacs breakage that should get fixed.

How can I get emacs to open a new buffer quickly?

I used to be able to open a new buffer in Emacs quickly using the command C-x b <non existent buffer name>
Somehow I've broken this in my version of Emacs (23.1). When ever I try to do this now I get the message [No match] in the command buffer.
Does anyone know what I might have done to break this functionality, or is it possible that I imagined being able to do this?
Set confirm-nonexistent-file-or-buffer to nil:
confirm-nonexistent-file-or-buffer is a variable defined in `files.el'.
Its value is after-completion
Documentation:
Whether confirmation is requested before visiting a new file or buffer.
If nil, confirmation is not requested.
If the value is `after-completion', confirmation is only
requested if the user called `minibuffer-complete' right before
`minibuffer-complete-and-exit'.
Any other non-nil value means to request confirmation.
This affects commands like `switch-to-buffer' and `find-file'.
You can customize this variable.
This variable was introduced, or its default value was changed, in
version 23.1 of Emacs.
If you have enabled ido-mode, you can still switch to the behavior you're familiar with. I do this frequently when I know I'll be creating a new named buffer.
C-x b C-b
You press C-j instead of hitting enter twice, which will bypass the confirmation and immediately open the new buffer. This works with or without ido-mode. This will have the same effect has pressing enter with confirm-nonexistent-file-or-buffer set to nil.
You probably enabled ido-mode. You need to press ENTER to confirm the creation of the buffer.