On my old system (Linux Mint 18.3), every time I used the less command and quitted (q), the last viewed page of less remained on the terminal (bash) view
On my new system (Min 19.3), when I quit 'less', everything fades, as if less was never opened (similar to what happens with 'nano' command, for example)
Is there a way to make less behave like in my old system? It was very useful when working e.g. with git logs
From man less:
-X or --no-init: Disables sending the termcap initialization and deinitialization strings to the terminal. This is sometimes desirable if
the deinitialization string does something unnecessary, like clearing the screen.
Related
Assume I want to invoke a tool with a lot of options, like:
$ somescript --option1 --option2 --option3 --option4 --option5 whatever even more stuff
But the width of the terminal doesn't allow to have that thing on a "single line".
That alone isn't a problem, but with fish, there is a problem with scrolling.
When I enter that extra-wide command, at some point, there will be a line break:
$ somescript --option1 --option2 --option3 --option4 --option5
whatever even more stuff
All fine so far. While typing such a lengthy command, I can scroll forth and back at any point. Works as expected. So, assume I entered the command, made a mistake, and now want to remove --option4.
The normal thing: use "arrow up" to get to that command in the history, to then use "arrow left" to scroll within the command. And now something weird happens.
Everything is fine while the cursor is within the second line. But when the cursor moves to the first line ... after 3 to 5 more "arrow left" strokes, the cursor moves UP another line. Then it sits above the first line of the command. There is also a vertical jump of a few characters.
In other words: as soon as a command is longer than the width of the terminal, I am unable to scroll into the first line reliably. The cursor shows up somewhere, and it is really hard to guess where it really sits at any moment. Which makes it almost impossible to edit anything in that first line.
This is on MacOs, using iterm 3.2.9 and fish version 3.0.2 installed via brew.
Wrote up defect 6014 on github. Outcome is rather frustrating.
The problem is: the Mac terminal(s) all handle certain unicode characters the wrong way. "Normally" that isn't a problem, but when you use one of those fish prompts that give you the git status (like AcidHub which is my favorite) ... fish can't compute/determine the exact line width, and there you go.
So, basically, when using fish on MacOs, option space is limited to:
use the defaults, which (when using special prompts, like AcidHub will lead to scrolling issues)
adapt the fish prompt accordingly (in my case, I replaced all special unicode chars with something simpler). It doesn't look that great, but scrolling simply works again.
And a completely different and unexpected solution to the problem: I am using iterm2 on my Mac, and iterm2 just added a "status bar" section. That can be easily configured, and of course, it already has a status bar component that tells you about git status.
Thus my solution: I changed the fish prompt to just give the PWD, and all the other things that the AcidHub prompt has to offer, are now "iterm2 status bar" components!
I'm aware of the use of lisp funcitons window-configuration-to-register and jump-to-register, and also packages like desktop.el and winner-mode.
These can all be used to save a layout during a session and recover it sometime later. I can get these to work nicely.
However if I'm running in daemon mode and am attached via emacsclient - if I try save a layout to a register, for example - I do not seem to be able to recover this layout in a separate emacsclient on the same daemon using any of the above methods - even though they share exactly the same windows.
Can anyone suggest a lisp function or any other methodology to allow to persisting of a client window layout after closing the original emacsclient session?
I should add I have no option but to use use emacs in console.
Update:
To half-answer my own question -
Saving the frame configuration to a register seems to work:
C-x r f – frame-configuration-to-register
C-x r j – jump-to-register
It's a bit shakey - when you jump back to the register you seem to have to exit the frame using 'C-x 5 0'.... after that you're still left with an underlying client frame that you can exist using 'C-x C-c' without killing the daemon.
If you try to directly exit the register stored frame using other methods it will either not work at all, or you'll kill the daemon entirely!
So it looks to me like jumping to the register seems to kinda grab ownership of the daemon process.
So follow-up questions:
1) Is there a way to make this play a bit nicer with the daemon?
2) Is there a way to automatically save your frame to a register (which will persist on the daemon) when emacs client exits or dies?
2nd Update
Actually having used it for a day - the above doesn't really work at all - the behaviour is random when restoring windows - sometimes it works, and it is often impossible to quit the emacsclient using any command!
I often find myself running kill on the emacsclient - which in-turn kills the daemon process as well as the client!
To answer my own question and having tried many ways to achieve the above, I've only found one method that at least so far has proved stable/reliable even when using the daemon - this is to use the workgroups2 pacakge that is available on Melpa.
I also noted that the original workgroups package (of which workgroups2 is a more recent fork) also works, but has more limited funcitonality. This is also available from Melpa.
The key default commands on workgroups2 that will interest you are:
C-c z c - create
C-c z v - view
I refer you to the manuals for more details - I've included reference links below to the 2 packages
https://github.com/tlh/workgroups.el
http://workgroups2.readthedocs.io/en/latest/
I am using run-octave in Emacs to trigger octave. Something is acting abnormally.
Every time I hit TAB to complete, there would be a tailing ^M; If I edit a .m file using edit a.m, it would start a new frame instead of a new buffer and the prompt is waiting for the closure of that frame so it would not respond to any input. How could I configure .emacs so that run-octave would behave normally?
Any comment is appreciated!
You seem to have two problems. I'm not sure about the trailing ^M, which seems to be caused by some sort of Windows/Unix CR/LF problem, but maybe I can help with the second problem.
The edit command uses the EDITOR environment variable to decide what to run. It seems that yours is either set to emacsclient or has defaulted to it. You haven't said whether you're on Unix or Windows, so I'm going to assume the former: you'll have to change this a bit for Windows.
To avoid the waiting thing, try running octave with a different EDITOR. For example, try out running
EDITOR='emacsclient -n' octave
When you type edit foo, it should bring up an Emacs buffer (if you want a new frame as well, use -c too) but not wait until you're done.
If this fixes things for you, you could change your ~/.bashrc to include the line
export EDITOR='emacsclient -n'
I'm using zsh in OS X Terminal.app and for quite a while, I've been longing for a way to jump back and forth between prev/next prompts in the terminal's output.
One convenience with this would be to be able to review (and track errors at) the end of each command's output; eg. when you building stuff from source with ./configure; make; make install. Note: I'm obviously not referring to jumping back and forth in the command-history, but for a way to take a peek at the endings of each command's output.
Has anyone heard of such functionality in the *nix (preferrably also Mac) world? Would it require some sort of OS-centric Terminal plugin, or can it be programmatically done via a shell script which can be tied to a keyboard shortcut? Maybe I'm the only one thinking about this? :)
Edit: Here's an example scenario: Let's say I want to compile and install some program (using standard ./configure && make && make install procedure) and after the make command, I run into some errors. Now, the way I understand it (I may be completely wrong), the crucial error causing the make command to fail usually shows up in the last line(s) in the output, no? Anyway, at this point, I might do something like cat INSTALL to read up on the INSTALL document to check whether there's something I've missed. NOW, if I want to go back to see what the error was, that caused my initial make command to fail, I then have to manually scroll up to that position again, since my cat INSTALL command printed a ton of text after it.
I don't know if this scenario is the most elucidative – but there are many other situations where I wish I could just "jump" back to previous prompt lines and check up on previous command output; whether it was a simple ls command, make, git status, or whatever it was – swapping positions in the window by means of using prompt lines as "bookmark" positions seems an interesting idea to me.
command + left or right goes between tabs in iterm. is this what you are asking?
Emacs has a shell-mode that runs a shell inside the Emacs editor, providing a rich environment of additional commands for navigating and working with shell commands. This includes commands for going to the previous/next prompt, and deleting the output from commands so you can "clean up" and issue another command.
If you aren't familiar with Emacs: to start a shell inside Emacs, run emacs from the shell, then type Esc-x (or Meta-x, if you have "Use option as meta key" enabled in Terminal > Preferences > Settings > [profile] > Keyboard). This will ask for a command to execute. Enter shell.
To see a list of commands you can use in Shell Mode, enter Control-h m. Here are the ones for moving the cursor to the previous/next prompt:
C-c C-n comint-next-prompt
C-c C-p comint-previous-prompt
These commands would also be useful:
C-c C-r comint-show-output
C-c C-o comint-delete-output
I installed the new release of emacs 23.1 and the very first difference I saw is that after M-x find-grep it takes 5-7 sec to show the standard command "find . -type f -print0 | xargs -0 -e grep -n ".
In release notes for 23.1 there is something about "Smarter minibuffer completion". Can I disable this feature and return to the old implementation when the command appeared immediately?
ANSWER: It is necessary to put somewhere in .emacs
(setq grep-highlight-matches nil)
to avoid a call (grep-probe) which takes a long time
Does it get faster after the first time you run it, or is it consistently slow?
It looks like find-grep (which is just an alias for grep-find, nice!) runs grep-compute-defaults to set up a bunch of meta-information (location of grep, how to invoke find, etc); I wonder if that's the slowness you're seeing? It looks like you may be able to save the value of grep-host-defaults-alist and side-step this process? (With the caveat that if anything ever changes, etc...)
Answering your second question about minibuffer completion, this setting will get you back to the completion used in Emacs 22:
(setq completion-styles '(emacs22))
However, that doesn't address the slowness like you'd hope. The slowness probably has something to do with your system. Maybe the package had to be read in and the disk was busy, or your system was loaded or ... 'find-grep works very speedily for me (and I'd bet the same for most everyone else).