gmane.emacs.devel

Re: "system-process-attributes" function name

Eli Zaretskii — 2008-12-04T04:21:25

Because unfortunately the "process-" prefix is used by many Emacs primitives that only handle Emacs subprocesses, not just any arbitrary process running on the machine. I agree that it is slightly awkward, but I thought confusing that with Emacs subprocess support was a greater evil, and at least Roland Winker, the author of proced.el, which is the primary user of these new primitives, suggested the same names. There's only one more: list-system-processes.

"system-process-attributes" function name

Miles Bader — 2008-12-04T03:40:06

I just noticed this new function (from a msg by Thierry Volpiatto), and wonder -- why the funny prefix "system-"? It seems both misleading (a "system process" is typically one that's running as root, and the question that immediately comes to mind is "how do I get the attributes of a user process?") and unnecessary. Why not just call it `process-attributes', and accept either a pid or an emacs process descriptor? That would be easy to implement, and would be both more convenient and easier to find for programmers. [I haven't looked at the other "system-process" functions, but a similar comment might apply to them.] -Miles

Re: y-or-n-p and emacs --daemon

Dan Nicolaescu — 2008-12-04T03:02:33

> >> Bad idea: > >> (unless (y-or-n-p "Stop me from removing all your files") > >> /bin/rm -rf / > >> ) > > Such a question would be a bug that we need fixing. Usually Emacs is > pretty consistent in asking questions in such a way that `n' is > a safe answer. That's not safe enough, this might happen for code that is in the user's .emacs. > >> Ignore it, or fix it properly: so that it works like y-or-n-p when > >> using -batch. > > I don't think that would solve the problem either, since AFAIU the > > daemon might not have a user accessible terminal at all (as bug#1310). > > Does someone know the reason for this problem? E.g. it's not clear to > me why the y-or-n-p question is displayed (even though it's after > "Starting Emacs daemon", so stdout should have been closed) but the "Starting Emacs daemon" is printed at the beginning of `command-line-1', before detaching. --eval is also run before detaching. > answer is ignored (or is it?). It's not ignored, the input

Re: y-or-n-p and emacs --daemon

Stefan Monnier — 2008-12-04T02:16:42

Such a question would be a bug that we need fixing. Usually Emacs is pretty consistent in asking questions in such a way that `n' is a safe answer. Does someone know the reason for this problem? E.g. it's not clear to me why the y-or-n-p question is displayed (even though it's after "Starting Emacs daemon", so stdout should have been closed) but the answer is ignored (or is it?). Ideally, either the question comes before detaching and it should then behave as it does in -batch, or the question comes after detaching and it should then wait for a frame to be created to display the question in there. Stefan

Re: hash-table-{to, from}-alist

Stefan Monnier — 2008-12-04T02:05:54

Some nitpicks, see below. BTW, have you tried to delegate to some Elisp code? We like to avoid putting comment markers on their own line. So we'd write /* Accept extended format for hashtables (extensible to other types), e.g. #s(hash-table size 2 test equal data (k1 v1 k2 v2)) */ We like to terminate our comments like sentences: with a sot followed by 2 spaces. We like to put the body of the `if' on a separate line. Comments should be capitalized: /* This is the hashtable data. */ We recently decided it was OK to use ANSI C syntax for function headers, but I don't think ANSI C allows such variable declarations in the middle of a block. So we should probably move the delcaration of those 2 vars higher up, or open up a new block. Other than that, it looks good. Stefan

Re: Interesting combining character issue

Kenichi Handa — 2008-12-04T01:49:49

Stefan> I do not see this problem here. Neither using wget nor opening Stefan> it directly (with url-handler-mode). I still can't reproduce it even with DejaVu Sans Mono. Please send me your DejaVu Sans Mono font file. --- Kenichi Handa handa< at >ni.aist.go.jp

Re: y-or-n-p and emacs --daemon

Stephen J. Turnbull — 2008-12-04T01:05:40

> IMO redefining the meaning of y-or-n-p is still not a good idea. The problem is that y-or-n-p is not defined at all if there's no interactive terminal. It's not a redefinition.

Re: y-or-n-p and emacs --daemon

Dan Nicolaescu — 2008-12-03T21:53:06

> Dan Nicolaescu ics.uci.edu> writes: > > > > The only thing I can think of is to make y-or-n-p and yes-or-no-p > > > default to "no" when only the daemon's dummy terminal is open. > > > > Bad idea: > > (unless (y-or-n-p "Stop me from removing all your files") > > /bin/rm -rf / > > ) > > > > > Does anyone have a better suggestion? > > > > Ignore it, or fix it properly: so that it works like y-or-n-p when > > using -batch. > > I don't think that would solve the problem either, since AFAIU the > daemon might not have a user accessible terminal at all (as bug#1310). Bug#1310 is a long standing Gtk+ bug, Jan has made workarounds for it a few times, and it is looking at this instance too. So that bug is not related to this issue. BTW, the patch in #1310 is probably correct. > What we could do is to make y-or-n-p signal an error. IMO redefining the meaning of y-or-n-p is still not a good idea.

Re: y-or-n-p and emacs --daemon

Chong Yidong — 2008-12-03T21:07:54

I don't think that would solve the problem either, since AFAIU the daemon might not have a user accessible terminal at all (as bug#1310). What we could do is to make y-or-n-p signal an error. Individual callers will then have to check for daemon-mode and do something else before calling y-or-n-p; which is also probably the way to fix bug#1310.

Re: [Patch] Allow a function as value of `appt-display-format'

Tassilo Horn — 2008-12-03T20:50:43

Hi Glenn, Nothing. ;-) If you hadn't mentioned it I wouldn't have found out about appt-disp-window-function, so at least the docs have to be improved. Or we use my version, drop `appt-disp-window-function' and call `appt-disp-window directly' in the `window' case. I'd vote for the latter solution and volunteer to do it. Bye, Tassilo

Re: multi-threaded Emacs

Stefan Monnier — 2008-12-03T20:14:16

Actually, yielding in QUIT will take a lot of work. It's definitely not "cooperative" seen from Elisp's point of view (where QUIT can be run implicitly all over the place). By cooperative thread model, I mean that we can switch context either when we already do (i.e. when waiting for user/process/network input), or when running some new `yield' Elisp function. As written above (and earlier as well), Emacs will switch threads when waiting for network input. Stefan

RE: invisible mouse pointer?

Stephen J. Turnbull — 2008-12-03T20:06:49

> Thanks, Thierry. Actually, I'm not interested in this behavior for > myself. The idea was inspired by a request at help-gnu-emacs. I > know that some people are bothered by the pointer, and I thought > such a feature might help them. But yes, the idea would be to be > able to do it at the Emacs level. XEmacs allows you to set the shape of the pointer by changing the image property of a pointer-glyph. Normally these are taken from the standard X cursor font, but arbitrary images can be used (up to the limitation of the X server, of course). I don't know if it's possible to use an empty image, but you could certainly set it to a one-pixel image, possibly even the color of the pixel the mouse is currently "on". Maybe Emacs has a similar facility.

Re: y-or-n-p and emacs --daemon

Dan Nicolaescu — 2008-12-03T19:53:04

> Espen Wiborg grumblesmurf.org> writes: > > >> $ emacs-23 -Q --daemon --eval '(y-or-n-p "hello? ")' > >> > >> 1. It hangs indefinitely, > >> 2. it does not detach properly (it forks, but the parent doesn't exit), > >> 3. it doesn't start the server. > >> > >> Now the problem is that y-or-n-p is called from many places, so > >> depending on the configuration there is some chance that Emacs will > >> ask for user interaction before initialisation is finished. There is > >> even one in server-start (which AFAICS won't be triggered in daemon > >> mode, but still...). > > > > Actually, this yes-or-no-p *is* triggered in daemon mode, but only > > (AFAICT) in the case uncovered by bug #1310, where a client's X > > connection is lost and the daemon tries to shut down. > > The only thing I can think of is to make y-or-n-p and yes-or-no-p > default to "no" when only the daemon's dummy terminal is open. Bad idea: (unless (y-or-n-p "Stop me from removing all you

RE: invisible mouse pointer?

Drew Adams — 2008-12-03T19:52:17

Great. Maybe you and Thomas Fitzsimmons can compare patches and come up with something common after the release.

Re: [Patch] Allow a function as value of `appt-display-format'

Glenn Morris — 2008-12-03T19:41:49

What does this do that setting appt-disp-window-function does not do (apart from perhaps making the meaning clearer)? Please wait. Thanks.

Re: y-or-n-p and emacs --daemon

Chong Yidong — 2008-12-03T19:33:55

The only thing I can think of is to make y-or-n-p and yes-or-no-p default to "no" when only the daemon's dummy terminal is open. Does anyone have a better suggestion?

Re: Lisp error: (wrong-type-argument arrayp nil) when finding asymlink to a version controlled file

Tassilo Horn — 2008-12-03T19:29:40

Works again with an emacs from yesterday evening. Bye, Tassilo

Re: invisible mouse pointer?

Jan Djärv — 2008-12-03T19:28:52

Drew Adams skrev: I have a patch for this somewhere, but only for X11 Emacs. But we are in a feature freeze so... Jan D.

[Patch] Allow a function as value of `appt-display-format'

Tassilo Horn — 2008-12-03T19:27:40

Hi all, I use appointments but I don't like the possible display styles. So I added a new choice to `appt-display-format' which allows adding a function which does the job of displaying the message on its own. For example I set `appt-display-format' to a function which calls the external program notify-send to show the message. Here's the diff: --8<---------------cut here---------------start------------->8--- Index: lisp/calendar/appt.el =================================================================== RCS file: /sources/emacs/emacs/lisp/calendar/appt.el,v retrieving revision 1.94 diff -u -r1.94 appt.el --- lisp/calendar/appt.el24 Nov 2008 19:53:00 -00001.94 +++ lisp/calendar/appt.el3 Dec 2008 19:19:21 -0000 < at >< at > -122,9 +122,11 < at >< at > (defcustom appt-display-format 'ignore "How appointment reminders should be displayed. The options are: - window - use a separate window - echo - use the echo area - nil - no visible reminder. + window - use a separate window + echo - use the echo

Re: hash-table-{to, from}-alist

Ted Zlatanov — 2008-12-03T19:25:22

On Tue, 02 Dec 2008 16:58:41 -0500 Stefan Monnier IRO.UMontreal.CA> wrote: SM> No, it won't be freed automatically. Why not use `alloca' instead? SM> Also rather than 10, why not use something like XINT (Flength (tmp)) ? A static array was a much simpler solution in the end. SM> This constant should be called Qhash_table. OK, all the constants are named appropriately. SM> Why not :weakness, :rehash-size, :rehash-threshold? SM> (maybe even :test and :size, although IIUC we may prefer just `size' SM> and `test' for compatibility with XEmacs, tho I'm not sure how SM> important that is for this kind of data). To be consistent. If this will be used by many users and libraries, it's important to provide a printed representation that doesn't mix symbol conventions and is easy to parse. Similarly, I'd rather provide something compatible with XEmacs if there's a choice. SM> Also you need to put spaces before all your open parens. Done, thanks. I took your other suggestions, except I don't pas

Re: invisible mouse pointer?

Thomas Fitzsimmons — 2008-12-03T18:58:02

Hi Drew, "Drew Adams" oracle.com> writes: I also looked into this a while ago and couldn't find a way to completely hide the pointer, so I wrote the attached patch. Ideally this low-level functionality would be exposed through a new mouse avoidance mode, as you suggest. Tom