Why doesn't emacs have a fringe mode in terminal? - emacs

I am a hardcore vim user. With the introduction of evil mode and spacemacs, I am transitioning over to emacs from vim. I often edit my code in a dev server (for reasons that I cannot explain), and I have to run my editor in terminal mode. One thing, I am missing in Emacs (that is there in vim) is a gutter to display useful information like compile/lint errors, while coding. Emacs does have a fringe mode for GUI for this but not for terminals. Is there a particular reason for avoiding fringe mode in terminal in emacs?
My requirement is to view all the errors in one column (I am using flycheck), so that it is easy to glance through the code to find the lines that has errors. flycheck has three ways to highlight error (line/column/symbol). I would like the symbol in the line to be highlighted, but at the same time, I would like to see a column either on the left or right side of the code, that marks lines that has errors/warnings with some symbol. Flycheck does this when fringe mode is enabled, but there is no fringe mode for terminals. Is there a way to get this in terminals?

I think that you should use the function M-x flycheck-list-errorsthen you can see all the flycheck errors in a separate buffer:
I'm reading a ruby file that I use rubocop for lint error. If I use rubocop directly on terminal I get this:
$ cat dirty.rb
class Dirty
# This method smells of :reek:NestedIterators but ignores them
def awful(x, y, offset = 0, log = false)
puts #screen.title
#screen = widgets.map {|w| w.each {|key| key += 3}}
puts #screen.contents
end
end
if I get the errors with rubocop:
$ rubocop dirty.rb
Inspecting 1 file
W
Offenses:
dirty.rb:1:1: C: Style/Documentation: Missing top-level class documentation comment.
class Dirty
^^^^^
dirty.rb:1:1: C: Style/FrozenStringLiteralComment: Missing magic comment # frozen_string_literal: true.
class Dirty
^
...
...
...
1 file inspected, 13 offenses detected
Which is the same as in emacs:
Then I can check all the offenses with M-x flycheck-list-errors in a separate buffer:
This is a feature or function of flycheck, so you can use this to any code, that flycheck is getting the errors for you

Related

Use mit-scheme with REPL and editor together

I'm going through SICP course and as recommended installed mit-scheme. I want to use the REPL together with a scheme file. The reason is because I can add scheme code in the file and then run the commands in REPL. What I have works, but the problem is every time I edit the file, I have to quit terminal and reload the file for REPL to see changes.
Is there a way to reload the file easily or some other way for REPL to see changes from the file?
This my setup:
I installed mit-scheme with brew install mit-scheme
I have a local file named code.scm
In terminal, I load the file with mit-scheme --load /Users/name/Desktop/code.scm
Terminal now starts the REPL and everything works. The problem is that if I add new code to the file code.scm, I have to quit terminal and call this again: mit-scheme --load /Users/name/Desktop/code.scm
System details:
macOS Catalina - 10.15.6
Default Mac Terminal app - Version 2.10
MIT/GNU Scheme running under OS X
The text editor I use is Atom - 1.50.0
Question Edit #1 (Based on answer below)
I tried following instructions but this is complicated.
This is what I did:
Run mit-scheme < /Users/Desktop/code.scm
After this I ran mit-scheme --edit to open Edwin. I tried to use the code inside of the code.scm file but it doesn't recognize it. This is the code in code.scm file:
This is what I want to be able to do:
Notice in this picture, I can type a command, press enter and it automatically runs command. However, I want to be able to call (fib 5) and it references the function in code.scm file.
Could someone explain step by step how to do this? It's confusing looking at documentation for scheme websites.
There's actually a built-in load procedure available in the MIT Scheme REPL.
Evaluating
(load "path/to/file.scm")
causes the Scheme file located at path/to/file.scm to be evaluated at the top level (note that the double quotes around the file name are required).
And, as it turns out, this same function can be used to reload a file.
With this in mind, a possible "workflow" might look like this:
Create new source file
Evaluate (load "path/to/file.scm") in the REPL
Edit source file
Evaluate (load "path/to/file.scm") in the REPL
...etc.
Unfortunately, I don't think there is a built-in "reload" procedure.
But...if you find yourself reloading a lot (as I imagine you will), you can always quickly write your own at the beginning of a hacking session:
(define (reload)
(load "path/to/file.scm"))
And then just call (reload) whenever you make a change to your source file.
If you're interesting in using Emacs, I'd say it's worth a shot.
There's a bit of a learning curve, but it's not as steep as it looks up front :)
Also, I cannot recommend the Racket programming language(s) enough.
There is an incredibly straightforward way to set it up for SICP, and it's a much more forgiving environment than Emacs.
Let me know if you are interested and want any help getting started.
You should use emacs with xscheme.el. It works much better.
If you continue as you do, you can also do mit-scheme < code.scm or mit-scheme --edit code.scm and you will also get a *repl* buffer inside edwin.
I recommend you the emacs way, however.
A (load "/path/to/file") command should be available to you within MIT Scheme and the Edwin editor it comes with. However, I would actually recommend that you use Emacs, and use Geiser within that to access both the REPL and to help with scheme file editing. It also makes dealing with various Scheme REPLs such as Chez Scheme, Racket, MIT Scheme, Guile, Chicken, Gambit and Chibi Scheme fairly effortless. The same (load "/path/to/file") command would then be available to you within the REPL running under Geiser, within Emacs, but is generally much more powerful and seamless than when using the "naked" REPL. Emacs is very well tuned to use with Scheme and LISP. Highly recommended.
Evaluate entire buffer: press M-o (M is Alt on Windows). When in source file window, press it. It will evaluate the entire buffer i.e. (re)load the entire source file (without even saving it first). I found it by googling "mit scheme edwin tutorial". Edwin is kind of Emacs itself.
This page says: "C-c C-s when done in a scheme-mode buffer [i.e. Scheme source file window], will switch to the Scheme interaction buffer [i.e. REPL]". i.e. you press C-x C-s to save file, M-o to evaluate (i.e. load), C-c C-s to switch to the REPL.
If you've split your screen with C-x 2 between a source file buffer and the REPL ("interactions buffer"), you can switch between them by pressing C-x o (for "go to the other window").

emacs - stop adding indentation to current and next line when pressing RET

I have a file open called test.scss, and when I press RET on a line, emacs will add 2 spaces to the current line and 4 extra spaces to the next line.
I've highlighted what the file looks like with whitespace-mode.
before pressing RET
after pressing RET
You can see that the .my-element row was auto-indented by 2 spaces, and the new line is indented by 4 spaces too many.
I want the output to look like this instead
desired output
What can I do to make emacs produce my desired output?
Here is the output of describe-mode:
Enabled minor modes: Auto-Composition Auto-Compression Auto-Encryption
Electric-Indent File-Name-Shadow Font-Lock Global-Eldoc
Global-Font-Lock Line-Number Menu-Bar Tooltip Whitespace
(Information about these minor modes follows the major mode info.)
SCSS mode defined in `css-mode.el':
Major mode to edit "Sassy CSS" files.
In addition to any hooks its parent mode `css-mode' might have run,
this mode runs the hook `scss-mode-hook', as the final step
during initialization.
Although in this case I'm in scss-mode, I see similar behavior with most of the other modes I use, such as ruby-mode, sgml-mode, js.el mode and others. I'd like to make the behavior match the desired output shown above.
Each mode can handle indentation in its own way, and you may have to look for mode-specific settings to get two-space indentation working everywhere.
For starters, you can set css-indent-offset, which should cover css-mode and scss-mode:
(setq css-indent-offset 2)
You can set the basic indenting of many other modes similarly. ruby-mode seems to use ruby-indent-level, sgml-mode uses sgml-basic-offset, and js-mode uses js-indent-level.

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.

Terminal emacs colors only work with TERM=xterm-256color

I've found that terminal emacs does not render the correct colors unless I explicitly set TERM=xterm-256color. I use gnome-terminal, and from what I understand, TERM should be set to gnome-256color. Similarly, I tend to use tmux a lot, which advises against any TERM setting other than screen-256color. Unfortunately, both of those settings (within their respective context - gnome-terminal or tmux) result in emacs having wrong colors, whereas vim displays colors correctly. However, if I export TERM=xterm-256color, the colors work just fine in emacs.
Can anyone explain what's going on, or offer a solution?
Update
Here's what I'm dealing with:
I can get the colors to look correct in the terminal by adding the following to my init.el:
(defun terminal-init-gnome ()
"Terminal initialization function for gnome-terminal."
;; This is a dirty hack that I accidentally stumbled across:
;; initializing "rxvt" first and _then_ "xterm" seems
;; to make the colors work... although I have no idea why.
(tty-run-terminal-initialization (selected-frame) "rxvt")
(tty-run-terminal-initialization (selected-frame) "xterm"))
This feels really, really wrong though. There has to be a logical explanation for this...
P.S.
I have very little knowledge of terminfo and the precise role that $TERM plays in the process of color terminal behavior. If it's safe to always use xterm-256color (even when $TERM "should" be gnome-256color or screen-256color), I'll go with that.
Maybe I'm not understanding something, buy why don't you run emacs like this:
TERM=xterm-256color emacs -nw
This way Emacs has its own TERM setting that you know works. You can also make an alias or wrap this in shell-script.
Terminals are a special type of device. When a process sends special byte sequences (called control sequences) to the terminal, it performs some action (like cursor positioning, change colors, etc).
You can read the ANSI terminal codes to find more detail about control sequences.
But terminals come from 70s, when hardware was limited in its capabilities, and a terminal cannot provide info about its capabilities (ie. which sequences it supports).
$TERM was used to resolve this issue - it allows programs to know what to send to the terminal to get the job done. termcap and terminfo are databases that store info about terminal capabilities for many $TERM names. If your $TERM is not in the db, you must ask an administrator to add it.
All terminal emulators inherit these limitations from old hardware terminals. So they need a properly set $TERM, and the terminfo/termcap DB MUST have data for this terminal. When a virtual terminal starts it sets the $TERM variable for you (and inside programs like bash). If $TERM is not in the terminfo/termcap you can quickly define an alias from $TERM to xterm-256color (you can find examples in the termcap file on how to do that).
This behavior has to do with the logic EMACS uses to determine whether the terminal background is dark or light. Run M-x list-colors-display with TERM set to either xterm-256color or screen-256color and you'll see that the exact same colors are listed. As you pointed out in the comments, the difference in color schemes that you've observed is due to the frame background mode. To see this, with your TERM set to screen-256color, compare the colors in
emacs -Q -nw --eval "(setq frame-background-mode 'light)"
and
emacs -Q -nw --eval "(setq frame-background-mode 'dark)"
The function frame-set-background-mode (in frame.el) checks to see whether the terminal type matches "^\\(xterm\\|\\rxvt\\|dtterm\\|eterm\\)" if it can't deduce the background color otherwise.
Within a running session, you can change the color scheme to 'light by evaluating
(let ((frame-background-mode 'light)) (frame-set-background-mode nil))
I am not that familiar with how emacs handles different terminals exactly. But looking at lisp/term directory in emacs sources, I found out that the existence of a function terminal-init-xxx allows you to add support for different terminals. For example, I've got:
(defun terminal-init-screen ()
"Terminal initialization function for screen."
;; Use the xterm color initialization code.
(xterm-register-default-colors)
(tty-set-up-initial-frame-faces))
in my .emacs, which adds support for screen-256color. You may try defining a similar function for gnome by renaming the above function to terminal-init-gnome.
NOTE: If you are interested, you can try to track down the calls from tty-run-terminal-initialization code. It first gets the terminal type using tty-type function, then looks at certain locations to load a relevant terminal file, then tries to locate the matching terminal-init-xxx function, and finally calls it. It may help you figure out the correct name for gnome-terminal.
It looks like unless your TERM indicates that your terminal has 256 colors, emacs will only use 8. Changing TERM to gnome-256color allowed the color registration functions to work.
There is a way to cheat, after all. When I run gnome-terminal, my terminal is set to xterm by default. Instead of changing TERM variable, it is possible to redirect xterm to another terminal, say, gnome-256color. Simply create the directory $(HOME)/.terminfo/x, then run ln -s /usr/share/terminfo/g/gnome-256color ~/.terminfo/x/xterm. I think this is better than setting TERM manually in .bashrc, because it only redirects a particular terminal to something else. A console login would still leave TERM as linux, and not xterm-256color.
Add this to your ~/.emacs:
(add-to-list 'term-file-aliases
'("st-256color" . "xterm-256color"))
It tells emacs that if it sees TERM=st-256color then it should initialize the terminal as if it had seen TERM=xterm-256color.
Longer answer:
Emacs is showing strange colors because it thinks your terminal can only support 8 colors. In Emacs, run M-x list-colors-display to see the colors it thinks are available. The correct number of colors is detected during terminal-specific initialization. It says, in part:
Each terminal type can have its own Lisp library that Emacs loads when run on that type of terminal.
On my machine, the terminal-specific initialization files are in /usr/local/share/emacs/25.*/lisp/term. It has files for xterm, rxvt, screen, etc. but nothing for st. We need to help Emacs find the right initialization file. The documentation further says:
If there is an entry matching TERM in the term-file-aliases association list, Emacs uses the associated value in place of TERM
So that association list is a recommended way to handle unknown terminals. It works without you having to manually override the TERM environment variable.
On ubuntu 10.04 I too had noticed that running emacs -nw inside byobu/tmux/screen was using different colours from emacs -nw in the regular gnome-terminal.
I found that this is because byobu was setting TERM to screen-bce. Then setting TERM to xterm (for me, in the normal gnome-terminal TERM=xterm) gave me the same syntax highlighting when not running through byobu/screen.
So still not sure what the proper solution is.
See also this post:
Emacs Python-mode syntax highlighting

How can I script vim to run perltidy on a buffer?

At my current job, we have coding-style standards that are different from the ones I normally follow. Fortunately, we have a canned RC file for perltidy that I can apply to reformat files before I submit them to our review process.
I have code for emacs that I use to run a command over a buffer and replace the buffer with the output, which I have adapted for this. But I sometimes alternate between emacs and vim, and would like to have the same capabilities there. I'm sure that this or something similar is simple and had been done and re-done many times over. But I've not had much luck finding any examples of vim-script that seem to do what I need. Which is, in essence, to be able to hit a key combo (like Ctrl-F6, what I use in emacs) and have the buffer be reformatted in-place by perltidy. While I'm a comfortable vim-user, I'm completely clueless at writing this sort of thing for vim.
After trying #hobbs answer I noticed that when filtering the entire buffer through perltidy the cursor returned to byte 1, and I had to make a mental note of the original line number so I could go back after :Tidy completed.
So building on #hobbs' and #Ignacio's answers, I added the following to my .vimrc:
"define :Tidy command to run perltidy on visual selection || entire buffer"
command -range=% -nargs=* Tidy <line1>,<line2>!perltidy
"run :Tidy on entire buffer and return cursor to (approximate) original position"
fun DoTidy()
let l = line(".")
let c = col(".")
:Tidy
call cursor(l, c)
endfun
"shortcut for normal mode to run on entire buffer then return to current line"
au Filetype perl nmap <F2> :call DoTidy()<CR>
"shortcut for visual mode to run on the current visual selection"
au Filetype perl vmap <F2> :Tidy<CR>
(closing " added to comments for SO syntax highlighting purposes (not required, but valid vim syntax))
DoTidy() will return the cursor to its original position plus or minus at most X bytes, where X is the number of bytes added/removed by perltidy relative to the original cursor position. But this is fairly trivial as long as you keep things tidy :).
[Vim version: 7.2]
EDIT: Updated DoTidy() to incorporate #mikew's comment for readability and for compatibility with Vim 7.0
My tidy command:
command -range=% -nargs=* Tidy <line1>,<line2>!
\perltidy (your default options go here) <args>
If you use a visual selection or provide a range then it will tidy the selected range, otherwise it will use the whole file. You can put a set of default options (if you have any) at the point where I wrote (your default options go here), but any arguments that you provide to :Tidy will be appended to the perltidy commandline, overriding your defaults. (If you use a .perltidyrc you might not have default args -- that's fine -- but then again you might want to have a default like --profile=vim that sets up defaults only for when you're working in vim. Whatever works.)
The command to filter the entire buffer through an external program is:
:%!command
Put the following in ~/.vimrc to bind it to Ctrl-F6 in normal mode:
:nmap <C-F6> :%!command<CR>
For added fun:
:au Filetype perl nmap <C-F6> :%!command<CR>
This will only map the filter if editing a Perl file.
Taking hobbs' answer a step further, you can map that command to a shortcut key:
command -range=% -nargs=* Tidy <line1>,<line2>!perltidy -q
noremap <C-F6> :Tidy<CR>
And another step further: Only map the command when you're in a Perl buffer (since you probably wouldn't want to run perltidy on any other language):
autocmd BufRead,BufNewFile *.pl,*.plx,*.pm command! -range=% -nargs=* Tidy <line1>,<line2>!perltidy -q
autocmd BufRead,BufNewFile *.pl,*.plx,*.pm noremap <C-F6> :Tidy<CR>
Now you can press Ctrl-F6 without an active selection to format the whole file, or with an active selection to format just that section.
Instead of creating a new keyboard shortcut, how about replacing the meaning of the = command which is already in people's finger memory for indenting stuff? Yes, perlcritic does more than just indent but when you use perlcritic anyways, then you probably don't want to go back to the inferior "just indent" = command. So lets overwrite it!
filetype plugin indent on
autocmd FileType perl setlocal equalprg=perltidy
And now we can use = just like before but with the added functionality of perlcritic that goes beyond just indenting lines:
== run perlcritic on the current line
5== run perlcritic on five lines
=i{ Re-indent the 'inner block', i.e. the contents of the block
=a{ Re-indent 'a block', i.e. block and containing braces
=2a{ Re-indent '2 blocks', i.e. this block and containing block
gg=G run perlcritic on the entire buffer
And the best part is, that you don't have to learn any new shortcuts but can continue using the ones you already used with more power. :)
I'm used to select text using line oriented visual Shift+V and then I press : an I have !perltidy -pbp -et4 somewhere in history so I hit once or more up arrow ⇧.