Emacs crashes when I open a specific header file - emacs

I was digging through the header files for SDL in Linux when I tried to open the file from the SDL library called "SDL_opengl.h" in Emacs. For some reason, it always causes it to crash. It opens just fine in Vim and in gedit.
Has anyone else had an issue with Emacs just plain refusing to open a particular file? What sort of things should I look for to find what is causing the problem? Mind you, I was able to open every other "SDL_*.h" file in that directory; just that one gives me trouble.
Much appreciated in advance!

I would be interested to see the exact error message, and stack trace if possible.
I suspect file encoding, special characters, file size, cc-mode parsing, or something like that to be the culprit. (emacs 22 and libsdl1.2 on ubuntu 9 with utf-8 screen works fine for me)

Converting my comment into an answer b/c the comments get cut off.
Try loading the file with
M-x find-file-literally
Since this (appears to) resolve the issue for giogadi, I think that points to perhaps the colorization of the buffer. cc-mode does its own colorization...

Oh goodness, I'm a dunce.
So I apparently underestimated both the size of the file AND the speed of Emacs in opening said large files.
I decided to sit and wait to see if it dies completely on its own (as opposed to me xkill-ing it), and after a whole minute, the file is loaded.
So that solves one problem - the file is being loaded. However, why would Emacs take so long to do it? I have no strange settings enabled that should cause it to lag more than usual.

have you hilit-mode on?
with hilit-auto-highlight-maxout and a great value?
I have had the same problem with header-files, so reduce that value.
maybe it is hs-mode (hideshow-mode)?

Related

Phantom line display in Visual Studio Code IDE

In VS Code I have a tab with a plain text file I use for scratch while working during the day. I place all kinds code, questions, TODO lists, etc in this file and will reference it from time to time. It's helpful for history purposes.
At any rate, this file has ballooned up to well over 46,000 lines over the years and I'm now seeing this odd phantom line being injected at my cursor. I am unable to select it or remove it. I thought it was being displayed as VS Codes way of letting me know that a software update was available but when checking that was not the case. This is what it phantom line looks like, it seems to contain a history of CSS classes used over the years which is odd.
If I restart VS Code it goes away for a little while but then reappears. I have a feeling it might be because of the number of lines or perhaps memory but can't say for certain.
Has anyone else seen this behavior? I've probably enabled some setting by mistake and have no idea how to disable it.
Any suggestions would be greatly appreciated. Thank you!
Turns out it was the HTML End Tag Labels plugin that was trying to auto complete some HTML that was somewhere within the 46k lines.
I would have thought by identifying the file as type Plain Text, the plug-in would ignore trying to close HTML tags (since its not an HTML file) but alas that's not the case.
Thank you Mark Ahrens for the tip!

How do I limit the number of errors reported by flycheck

When editing a large file, flycheck-mode often takes 3-4 seconds to complete if an error "spills" over into the rest of the source file such that lots of lines are tagged with an error.
How do I limit the number of errors that the mode highlights such that it prioritizes the current buffer location?
Flycheck maintainer here.
You cannot “limit” error reporting currently in an easy way. At best, you can use a custom function for flycheck-process-error-functions, but that won't help you if the lag comes from something else, like error parsing.
And in general, I'd rather like to fix these lags than work around, if possible. Please open an issue at https://github.com/flycheck/flycheck/issues. Please add your Emacs version to the issue, and the amount of errors reported by Flycheck.
If possible, also give me the source file in private. You can find a mail address in the Github profile of Flycheck.

Odd Emacs behavior OSX 10.9.2 (Mavericks)

Emacs randomly started doing strange things on my mac -- I'm not sure exactly when it started; it could have been when I updated to Mavericks in the fall. Basically, it randomly doesn't allow me to edit certain lines of text, or it will display files incorrectly (i.e. it deletes some characters).
For example:
I just typed a .txt file containing "hihihi". Upon saving and then reopening the file in emacs, it only displayed "ihihi". This is a simple example...sometimes it deletes whole lines; regardless, this is extraordinarily annoying. However, I do know that it's not actually altering the file, because if I open the same file in Vim it still displays the original content. Emacs is just displaying the files incorrectly.
Has anyone experienced something similar and found a solution?
I've been trying to just install a newer version of emacs, but I think that I'm still running the old version, not the newer version that I installed with homebrew. If anyone has any suggestions for how to fix that I would also appreciate it!
Thanks!

Emacs indentation screwed up

I recently upgraded to emacs 24.3.1 in order to use a new mode for programming in D. I seem to have introduced some problem with my other modes now (Java, C++ C I'm just using whatever comes with emacs). When I scroll up/down in a buffer, the text displayed is totally messed up. As in lines mixed together, indentation screwy, cursor not modifying where it looks like it is. If I hit ctrl-l the screen refreshes and all is good. I noticed this problem every once in a while with my previous version when editing C .h files. But now it's happening on every single buffer. I can't work with it. Every time I move up/down I have to refresh the screen. I can't find anything similar to my problem with a google search. Might end up being an issue with some incompatible version of a dependency. Here's my system stats.
CentOS release 5.4 (Final)
linux 2.6.18-164.el5
emacs 24.3.1
I don't even know what other libs emacs might depend on. I'll be happy to post versions of anything that might be relevant.
Thanks
Since you say that this happens also with emacs -Q, i.e., without your init file, consider filing a bug report: M-x report-emacs-bug. For that, try to give a short, reprocible recipe, starting with emacs -Q. Emacs Dev will take a look and let you know whether they think there is a bug.
Using report-emacs-bug also automatically gathers info about your Emacs version etc., and includes it with your bug description.

Macro not working as expected in Notepad++

I just installed notepad++ and i am having some problems with macros in it.
i have a simple text file below:
hi
i am here
this is the third line
i kept the cursor at the first line before "hi".Now i selected start recording macro in the menu.i typed 'hi' before 'hi'(the actual word in the line) like below and pressed [Home] key in the keyboard and then pressed down arrow.Now i selected stop recording macro from the menu
hihi
i am here
this is the third line
but when i run the macro i am getting the following output
hihi
hˆi«i am here
hˆi«this is the third line
Could anybody please tell me where is the problem?
Upgrade to, at least, version 5.8.2 where that problem was fixed. I was experiencing the same problem, upgraded to version 5.8.5 and the problem is gone.
http://notepad-plus-plus.org/release/5.8.2
Fix macro recording bug for the non-ASCII characters.
same here as for Matt. For language, I was in normal text.
As mentioned in my comment at top, I have also been experiencing this same issue. Strange characters inserted when playing back a macro. This worked OK with previous versions, but appears to have been a bug introduced with version 5.7
It does appear to be an encoding issue. I have been able to workaround this issue by switching to UTF-8 encoding whilst recording the macro - as mentioned in the comment of this bug report.
This has been reported as a bug several times recently. Many are still open, however, one is reported as fixed. And is reported as fixed in the current release (5.8.2) - which also introduces several new features as regards macros. However, nothing later than v5.7 is yet available from the auto-updater within Notepad++ itself. However, you can manually download the latest installer from SourceForge.net.
I turned off the auto complete feature and this fixed the issue for me.
How do I stop Notepad++ from showing autocomplete for all words in the file
I had a problem, I typed in some code and it came out wrong in macro.
Then I neglected the advice to type the code and not paste it, and so I copy/pasted the code I needed and it worked fine.
So my advice: write it somewhere else and copy/paste when you start macro.