I have put some log messages in .emacs (emacs config file) like this,
(message "welcome to emacs")
I expected to see these messages in scratch buffer after emacs bootup, but it is not there. How can i add log to emacs boot code to understand it better & Where are those logs written to?
These messages are written to the *Messages* buffer. Apart from the usual ways of switching buffers, you can open this buffer by typing C-h e, or by clicking in the echo area.
(message "Foo") will write "Foo" to the *Messages* buffer, not to scratch. The scratch buffer is intended for evaluating pieces of Emacs Lisp code mainly. The message will also briefly appear in the minibuffer (until overwritten), so if your welcome message is the last piece of elisp in your .emacs, you should see "welcome to emacs" appear in the minibuffer, too.
Related
Today I was just experimenting with Linux shell. Here is what I did.
I wrote the output of clear to a file :
clear > clear.txt
Now I have some contents on the shell, (non-empty). Then I try to cat the contents of clear.txt
cat clear.txt
For my surprise, the entire screen got cleared. Can somone explain me why? if this is true, why cant we do the same for all the commands?
clear works very simply by transmitting a sequence of control codes which are interpreted by your terminal. The magic of actually clearing the screen is handled by your terminal (or terminal emulator, or console interface, or whatever you happen to be using) in response to receiving these control codes.
See also e.g. https://en.wikipedia.org/wiki/ANSI_escape_code
Well it's not a real explanation but it's how it is supposed to work:
http://man7.org/linux/man-pages/man1/clear.1.html
#CLEAR# writes to the standard output. You can redirect the standard
output to a file (which prevents #CLEAR# from actually clearing the
screen), and later cat the file to the screen, clearing it at that
point.
It is a visual representation of the clear command. Editing the text file yields:
^[[3J^[[H^[[2J
source: https://unix.stackexchange.com/questions/400142/terminal-h2j-caret-square-bracket-h-caret-square-bracket-2-j
I've read most of the manual and am slowly getting my head around the things I need to make major-modes, etc. I've not ran into anything that explains the loop/cycle that Emacs goes through to apply the major mode (or minor-mode even).
For example: I type if while in go-mode and suddenly if is syntax-highlight. I know that just typing common letters amounts to self-insert-command. So how does emacs then react to the change in the buffer unless either self-insert-command fires and event or just changing the buffer fires and event?
W.r.t syntax highlighting, this is triggered by any change to the buffer, no matter which command is used. To do this, the package taking care of keeping the highlighting up-to-date (typically jit-lock on behalf of font-lock) uses after-change-functions. See C-hv after-change-functions RET and also check the corresponding documentation in the Emacs Lisp reference manual (reachable from the "Help" menu).
Relative Emacs newbie here, just trying to adapt my programming workflow to fit with emacs. So far I've discovered shell-pop and I'm quite enjoying on-demand terminals that pop up when needed for banging out the odd commands.
What I understand so far about Emacs is that shell is a "dumb" terminal that doesn't support any ansi control codes, and that makes it incompatible with things like ncurses that attempt to draw complex UI's on a terminal emulator. This is why you can't use less or top or similar in shell-mode.
However, I seem to be having trouble with ansi-term, it's not the be-all, end-all that it's cracked up to be. Sure, it has no problems running less or git log or even nano, but there are a few things that can't quite seem to display properly when they're running in an ansi-term, such as apt-get and nosetests. I'm not sure quite what the name is for it, but apt-get's output is characterised by live-updating what is displayed on the very last line, and then having unchanging lines of text scroll out above that line. It seems to be halfway between something like less and something dumber, like cat. Somehow ansi-term doesn't like this at all, and I get very garbled output, where it seems to output everything on one line only or just generally lose it's place and output things all over, randomly. In the case of nosetests, it starts off ok, but if any libraries spew out any STDERR, the output all goes to hell in a similar way.
With some fiddling it seems possible to fix this by mashing C-l and RET, but it's not always reliable.
Does anybody know what's going on here? Is there some way to fix ansi-term so that it can display everything properly? Or is there perhaps some other mode that I don't know about that is way better? Ideally I'd like something that "just works" as effortlessly as, eg, Gnome Terminal, which can run all of the above mentioned programs without a single hiccup.
Thanks!
I resolved this issue by commenting out my entire .emacs.el and then uncommenting and restarting emacs for every single line in the file. I discovered that the following line alone was responsible for the issue:
'(fringe-mode 0 nil (fringe))
(this line disables the fringes from inside custom-set-variables).
I guess this is a bug in Emacs, that disabling the fringe causes term-mode to garble it's output really badly whenever any output line exceeds $COLUMN columns.
Anyway, I don't really like the fringes much at all, and it seems I was able to at least disable the left fringe without triggering this issue:
(set-fringe-mode (cons 0 8))
Maybe apt-get does different things based on the $TERM environment variable. What happens if you set TERM=dumb? If that makes things work, then you can experiment with different values until you find one that supports enough features but still works.
Note that git 2.0.1 (June 25th, 2014) now better detects dumb terminal when displaying verbose messages.
That might help Emacs better display some of the messages received from git, but the fringe-mode bug reported above is certainly the main cause.
See commit 38de156 by Michael Naumov (mnaoumov)
sideband.c: do not use ANSI control sequence on non-terminal
Diagnostic messages received on the sideband #2 from the server side are sent to the standard error with ANSI terminal control sequence "\033[K" that erases to the end of line appended at the end of each line.
However, some programs (e.g. GitExtensions for Windows) read and interpret and/or show the message without understanding the terminal control sequences, resulting them to be shown to their end users.
To help these programs, squelch the control sequence when the standard error stream is not being sent to a tty.
I'm building an application in PostScript that needs to take input fom the user at a prompt (I will be using the GhostScript executive, and the file won't be sent to the printer). I can't see anything in my PostScript Language Reference Manual that suggests this is possible, and I don't want to drop back to the executive, so is this possible?
It's not that hopeless! But it ain't exactly easy, either. There are two other special files besides %stdin that you can read from. (%lineedit)(r)file dup bytesavailable string readstring pop will read a line from stdin into a string. There is also the (%statementedit) file which will read until a syntactically valid postscript fragment is typed (plus newline). This will match parentheses and curlies, but not square brackets. Before reading, you should issue a prompt like (> )print flush.
One more thing, you can catch ^D by wrapping all this in a stopped context.
{ %stopped
(> )print flush
(%lineedit)(r)file
dup bytesavailable string readstring pop
} stopped not {
(successfully read: )print
print
}{
(received EOF indication)print
}ifelse
Instead of popping that bool after readstring, you could use it to cheaply detect an empty input line. Note also, that the stop that triggers on EOF is from an error in file (ghostscript calls it /invalidfilename), but although file is defined as an operator, and operators are supposed to push their arguments back on the stack when signaling an error, I've noticed ghostscript doesn't necessarily do this (I forget what it leaves, but it's not 2 strings like you'd expect), so you might want to put mark in front and cleartomark pop after this whole block.
The special files (%lineedit) and (%statementedit), if available, will successfully process backspaces and control-U and possibly other control. I believe real Adobe printers will respond to ^T with some kind of status message. But I've never seen it.
PS. :!
I've got a more extensive example of interactive postscript in my postscript debugger. Here's a better version of the debugger, but it's probably less useable as an example.
PostScript isn't designed as an interactive language, so there is no great provision for user input.
You can read input from stdin, and you cat write to stdout or stderr, so if those are wired up to a console then you can theoretically prompt the user for input by writing to stdout, and read the input back from stdin.
Note that reading from stdin won't allow the user to do things like backspace over errors. At least not visually, the data will be sent to your PostScript program which could process the backspace characters.
That's about the only way to achieve this that I can think of though.
I'm writing a command interpreter like BASH, and a \ followed by a newline implies a continuation of the input stream; how can I implement that in Win32?
If I use the console mode with ENABLE_LINE_INPUT, then the user can't press backspace in order to go back to the previous line; Windows prevents him from doing so. But if I don't set ENABLE_LINE_INPUT, then I have to manually reposition the cursor, which is rather tedious given that (1) the user might have redirected the input stream, and that (2) it might be prone to race conditions, and I'd rather have Windows do it if I can.
Any way to have my newline and eat it too?
Edit:
If this would require undocumented CSRSS port requests, then I'm still interested!
Assuming you want this to run in a window, like command prompt does by default, rather than full screen, you could create a GUI application with a large textbox. Users would type into the textbox, and you could parse whatever was entered, and output to the same box (effectively emulated the Win32 Console).
This way whatever rules you want to set for how the console behaves is completely up to you.
I might be mistaken is saying this, but I believe that the Win32 Console from XP onward works exactly like this, and it just listens for output on stdout; there shouldn't be any reason you can't do the same.
Hope this was helpful.