In Emacs sql mode or lisp mode connected to an inferior SQLi or Lisp process, there's a limit to how much data I can send to the process buffer in one go. Over the limit some or all data is lost.
I've tried to find what the limit is by running a comint process which simply reads input and echoes it. The limit seems to be around 760 characters.
I'm running emacs 25.4.1 on a very old HP-UX B.11.11. I've built emacs myself using gcc 4.2.3 which is the best I can get on this box. As far as I can tell no-one else reports a similar problem, so I'm wondering if something was amiss in the build process, but I don't know where to look.
Related
I'm not sure what the normal behaviour is here, but I would like to have multiple workgroups, each with its associated buffers. So, for example, I could have my-python-workgroup which has a bunch of python files open in the buffer, and a my-ssh-workgroup which has buffers associated with a server connection.
Right now it seems like once I launch emacs and switch between workgroups, my buffers end up accumulating. Is there any way to keep buffers separate?
Spacemacs has this capability through what it calls 'Layouts'. Layouts gives you buffer isolation, so that you can keep your python and ssh buffers in separate groups, for instance. You can also save and load layouts. See here:
https://github.com/syl20bnr/spacemacs/tree/master/layers/%2Bspacemacs/spacemacs-layouts
The disadvantage is that it does not save shells (ehsell, ansi-term, inferior python, etc.), so you can't load up a combination of python files and an inferior python buffer on restart. Workgroups2 has this capability, but it does not allow buffer isolation. It would be great if these two concepts could be combined!
The echoing is very slow.
Would it be good for emacs to truncate strings greater than certain number of chars?
How could I do this?
The culprit is comint-mode, where the (I)Python shell is built upon. For these cases of very large output python-mode.el offers a way to avoid comint-mode, see py-fast-process-p.
Is there a good cross-platform method for determining the number of processors a machine has in elisp? I'm trying to make my config auto detect some build options, and would like to have it automatically use the number of processors + 1. Grepping /proc/cpuinfo isn't a solution for me because it won't work on Windows.
Emacs 24.3 Lisp doesn't have access to that information. Your options would seem to include:
writing an Elisp library which uses the value of SYSTEM-TYPE to choose a system-specific method for getting the processor count;
modifying the Emacs C source and rebuilding it so that it can, for each potentially multiprocessor platform on which Emacs builds, expose the processor count at the Lisp level.
At least, that was true four hours ago, when I first started writing this answer. But then I got interested in the problem, and now you have a third option:
downloading my system-cores.el library, which implements the first of the two options above, and calling (system-cores :physical) to get the number of physical processors, (system-cores :logical) to get the number of logical cores, or just plain (system-cores) to get an alist containing both.
Caveats include:
This library relies strongly on the PROCESS-LINES function. If that function can't do anything sensible in the context where you need to call SYSTEM-CORES, then SYSTEM-CORES can't either. (For example, if you're on Darwin and (getenv "PATH") doesn't contain /usr/sbin, PROCESS-LINES will bomb out with "Searching for program: no such file or directory, system_profiler".)
The systems currently known to be supported are GNU/Linux (anything with /proc/cpuinfo, more or less), Windows NT (and its derivatives, including 2000, XP, and all subsequent versions), and Darwin (OS X, at least 10.8, theoretically as far back as 10.2). Not coincidentally, these are also the systems to which I have access.
I've also included a delegate which should work properly on at least some flavors of BSD, but I don't have a BSD box on which to test it, so there's no telling whether or not it'll really work -- at the very least, you'll almost certainly need to modify the list of sysctls examined by the SYSTEM-CORES-SYSCTL delegate.
If you're using a modern variety of Linux, Windows, or OS X, great! You should be good to go, right out of the box. If not, and if your platform includes a command-line utility which provides the requisite information in its results, then it shouldn't be hard to write a delegate for your system. Or, if you don't want to write a delegate yourself, then email me all of:
the proper invocation for the command-line utility in question
a sample of the output it produces on your system
the output of M-: system-type in Emacs
the output of M-: system-configuration in Emacs
and I'll be able to write a delegate myself and add it to the library.
Edit: The :cores and :processors keywords have been replaced with :physical and :logical, respectively; I couldn't keep them straight, and I don't see why I should expect anyone else to, either.
Edit: Per #lunaryorn, replaced (split-string (shell-command-to-string ...)) with (process-lines ...). This saves invoking a shell, which might make the library more reliable, and certainly makes its code easier to read.
How would you automatically "record" a slime repl session? By "record" I probably mean to auto-save what the repl buffer has, similar to any code buffer's auto-save. I'm sure "state" would be a much tougher issue, but at least to save the buffer contents would be a start. Of course I could just do a save C-x-s and name it something like repl20131115-111034.srepl, but to have a behind-the-scenes auto-save capability (including timestamp in the file name) would be nice.
Psychotherapy
I asked this question about Lisp 20 years ago, about R a year ago and I am not asking it about python now. So, let me try to answer it.
What you asked for
Timed Logs
You certainly do not want the automatic repl-timestamp.log files - they will fill up your disk and you will never actually look at them.
Auto Save
Yeah, you can save the lisp interaction buffer into a file (and then the buffer will be auto-saved periodically), but you do not want that either.
You are much better off typing your code in a buffer associated with a lisp file and sending it to the lisp interaction buffer, and only copying the "interesting" lisp output back to your file buffer. E.g., you do not want to save all 42 bad versions of a function, just the working one (and maybe a few intermediate ones - but you have git and hg for that).
What you really need
What you really want it two things:
Remember what you did
Restore the state where you left off
Here is how to do that:
Remember what you did
You can use dribble to save into a file both what you type and what Lisp replies.
This is useful, however, I think I examined only very few of the zillions of dribble files I created in my newbie days.
They are there mostly for your peace of mind.
Restore the state
This is what lisp images are for: they write to disk the "state of the lisp universe" so that you can start from where you left off.
Is there a way to improve emacs tramp performance? For me it's faster to open an external ftp client (filezilla), transfer files to the local disk and open them in an external editor (notepad) than open them with emacs.
I use emacs23.1 under windows xp.
I tried different tramp-default-method (telnet, pscp, ftp), all of them have the same performance.
Profiling results with elp-instrument-package are the following (I opened 3 remote files of 1.5 MB each one)
tramp-file-name-handler 1461 350.41599999 0.2398466803
tramp-sh-file-name-handler 1461 350.02699999 0.2395804243
tramp-send-command 227 179.63400000 0.7913392070
tramp-send-command-and-check 205 177.77600000 0.8672000000
tramp-wait-for-regexp 227 176.47800000 0.7774361233
tramp-wait-for-output 226 176.40000000 0.7805309734
tramp-barf-unless-okay 18 133.46699999 7.4148333333
tramp-handle-insert-file-contents 3 132.046 44.015333333
tramp-handle-file-local-copy 3 131.281 43.760333333
tramp-accept-process-output 2375 112.95100000 0.0475583157
So, actual file transfer takes 132 sec, about 1/3 of total time. Why does it spend so much time in tramp-sh-file-name-handler? I tried to advice a function tramp-sh-file-name-handler to store and return cached results but it does not work, probably this function has some side effects.
Any ideas how to improve tramp performance? (I use emacs 23.1 under WindowsXP)
I've found that fuse-ssh is far better than tramp mode, if you can set it up that way.
if your use case improves, use remote client! I have resorted to editing remotely with emacs, this reminds me.
my experience has led me to believe the machine hosting emacs would be the bottleneck
however a better SSH client may help... try the list at OpenSSH.org (low in the left nav) I like PuTTY on Windows, where selection=copy & right-click=paste.
not sure of ways to improve the remote performance, though. the default build of emacs has a lot of lisp but it takes more disk than RAM space, and has always been efficient for me excepting large files & net/sys lag.
if your case has highlighting and auto-features you don't want, then configuring minimally might help - should be able to do that without rebuilding.
emacs is so vast, I noticed most when I found out it can send/receive e-mail. I have hardly explored the tip of the iceberg.
in this case though 'vi' may be better... even with more emacs experience relatively I've used small portions in each camp. rarely do I script or seek out a new feature, the digging is tough but there are handy command guides for both.
I resolved a problem by a couple of scripts which allow me to mget/put and mirror files or directories. These scripts use lftp (a version which is installed with the cygwin) and have a very good performance.
They were demands to publish my solution. Unfortunately, I have only a prototype of it. I have no time to finish it. It serves me well but it's not in the state to be published.