It seems to me that `open-rectangle' has a bug, or is not documented
correctly. Try the following:
Enter the following text:
This is a block of text. This is a block of text. This is a block
of text. This is a block of text. This is a block of text. This
is a block of text.
Would it be possible to configure what should happen when I drop a
directory into a dired buffer? The current behavior is extremely
annoying. I get this error:
Recursive copies not enabled.\nSee variable dired-recursive-copies.
I could change that variable but I do not want anything else than
Richard M. Stallman [EMAIL PROTECTED] writes:
I could change that variable but I do not want anything else
than the directiry opening in yet another dired buffer.
Do people generally agree that that is the right behavior for
dropping a directory into Emacs?
People will probably have
Reiner Steib [EMAIL PROTECTED] writes:
I could change that variable but I do not want anything else than the
directiry opening in yet another dired buffer. I don't want to drag
and drop directories to get them moved/copied/linked.
,[ f1 v dired-dnd-protocol-alist RET ]
|
Reiner Steib [EMAIL PROTECTED] writes:
Thanks, I found that variable in the code too, but I did not
understand how to configure that to get the behavior I want, i.e. to
just open the dropped directory in another dired buffer.
I thought the part When nil, behave as in other buffers. is
Reiner Steib [EMAIL PROTECTED] writes:
On Tue, Oct 18 2005, Mathias Dahl wrote:
Reiner Steib [EMAIL PROTECTED] writes:
I could change that variable but I do not want anything else than the
directiry opening in yet another dired buffer. I don't want to drag
and drop directories to get them
Richard M. Stallman [EMAIL PROTECTED] writes:
Experienced users who want something like that can use
delete-selection-mode. However, I'm concerned about beginners who
expect this behavior based on other editors.
Typing DEL after dragging a region is something that an experienced
Emacs user
Richard M. Stallman [EMAIL PROTECTED] writes:
Does this mean that you suggest DEL to do different things if I have a
mouse-dragged highlighted region versus if I have a highlighted region
made using something like C-a C-SPC C-SPC C-e DEL (temporarily
activate transient mark
[EMAIL PROTECTED] (Kim F. Storm) writes:
Stefan Monnier [EMAIL PROTECTED] writes:
I find Transient-Mark mode completely unusable as it stands.
To each his own. I find Emacs very hard to use without the visual feedback
of transient-mark-mode.
Me too.
Maybe we could move this part of the
Dieter Wilhelm [EMAIL PROTECTED] writes:
I'm sorry to say, but I don't think I can (and will) help you very
much. I'm just not a graphics, photograph or image friend and don't
collect pictures. I just want to have a simple way for checking some
graphics files without leaving Emacs.
I
Drew Adams [EMAIL PROTECTED] writes:
Looking at both the File Name Cache node in the Emacs manual and the Lisp
source code, I see nothing that indicates whether or not the cache is
persistent.
This is an important piece of information. The doc should make it clear that
the cache is not
[EMAIL PROTECTED] (Michaël Cadilhac) writes:
With latest CVS, I don't think this is already fixed neither I think
it's due to a compilation error:
$ emacs -q
$ C-h f tumme RET
describe-function: Symbol's function definition is void:
tumme-show-all-from-dir
I've added an
Richard Stallman [EMAIL PROTECTED] writes:
Starting emacs -Q, I get an empty scratch buffer. Pressing PRIOR
(PageUp key on my keyboard), I get End of buffer Message, while I
should get Beginning of buffer.
It does not happen when I try it.
If I erase the *scratch* buffer first
I think this must be a misunderstanding. No one is talking about saving
changes without the user saying so. The purpose of the patch is that
Emacs should be able to ask the user at logooff/shutdown to save the
changes. The situation now is that the changes are thrown away if they
are not saved
Lennart Borgman [EMAIL PROTECTED] writes:
Lennart Borgman wrote:
I have already sent a patch for this, but I have got no response on
that. There is possibly disagreement on what to do, but something
should be done and I do believe that the correct fix should make Emacs
follow the guidelines
Andrea Russo [EMAIL PROTECTED] writes:
Nick Roberts [EMAIL PROTECTED] writes:
If you replace the calls to shell-command with calls to call-process does
that do what you want?
(shell-command COMMAND) -
(call-process shell-file-name nil nil nil -c COMMAND)
Yes it does! Thank you very much
I've already done this as Richard asked me to DTRT. I've also used
with-current-buffer where needed, and made the code fit on 80 columns.
Thanks!
The pretest has not started yet and it makes sense to fix all reported bugs
anyway.
I did not say I had anything against it.
I don't use Tumme
You asked if it was safe to fix this in Emacs CVS now.
Sorry, I misunderstood.
I see now. I've fixed this as you suggested with shell-command-switch.
Thanks!
An interactive function can be used non-interactively but
AFAICS the optional extra parameters for shell-command
control the
Stefan Monnier [EMAIL PROTECTED] writes:
- (setq ret (shell-command command nil))
+ (setq ret (call-process shell-file-name nil nil nil -c command))
(if (not (= 0 ret))
(error Could not resize image)))
(copy-file file new-file t))
BTW, I
Dieter Wilhelm [EMAIL PROTECTED] writes:
emacs -D -Q --fullscreen
M-x tumme dir
and tumme doesn't show the *tumme* buffer only a dired buffer inhabits
the screen!
Strange, it does for me. But I am testing it in a terminal now.
the tumme documentation string says Make a preview buffer for
Dieter Wilhelm [EMAIL PROTECTED] writes:
emacs -Q -D
M-x tumme [some dir]
tumme doesn't show the *tumme* buffer, just the dired buffer. Below
is the *Message* buffer content after the tumme call
Loading tumme...
Loading regexp-opt...done
Loading tumme...done
Loading image-file...done
Mathias Dahl [EMAIL PROTECTED] writes:
I have tried to debug this without any luck. My current theory is that
for some reason the last `forward-char' is called when point is at the
end of the buffer. See if the following change in `tumme-line-up'
fixes the problem for you:
*** 20,26
? Funny when loading `tumme' for another directory with 16 pictures it
works, the thumbnails are shown immediately!!!
Yeah, I was almost sure that would be the case. For some reason, 9 is
a fringe case on your system. I tried various tests to try to get the
same behavior, but it always
Matt Hodges [EMAIL PROTECTED] writes:
The attached patch has two quick fixes for when the tumme associated
dired buffer is killed.
Thanks, I'd never dream of killing the dired buffer where I keep all (yes,
all) my images, so I would never have found this :)
I applied the patch.
/Mathias
Drew Adams [EMAIL PROTECTED] writes:
Only one variable is bound - no need for let*.
Is let better than let* if you do not need it? I suspect it is in some
way as you suggest the change, but I am curious how. :)
___
emacs-pretest-bug mailing list
Today I tried to use an old hack of mine (gds.el, loop it up on
EmacsWiki) and got an error from `utl-http'. I suceeded in recreating
it directly with this:
(url-insert-file-contents
http://127.0.0.1/;)
When I eval the above I get this:
Debugger entered--Lisp error: (error Could not create
Magnus Henoch [EMAIL PROTECTED] writes:
[ For the record: Mathias told me privately that open-network-stream
works as expected. ]
It struck me: maybe asynchronous connections don't work properly on
Windows.
Does (featurep 'make-network-process '(:nowait t)) return t? If not,
ignore the
Magnus Henoch [EMAIL PROTECTED] writes:
Mathias Dahl [EMAIL PROTECTED] writes:
Does (make-network-process :name http :buffer http-localhost
:host 127.0.0.1 :service 80
:nowait t)
work?
I get no error but it returns `nil'. I guess
Richard Stallman [EMAIL PROTECTED] writes:
If .JPG/.JPEG is frequent, perhaps we should add it to
`auto-mode-alist', then. Or do this:
(push '(^\xFF\xD8\xFF\xE0\x00\x10JFIF . image-mode)
magic-mode-alist)
I am not sure which is better, but I agree we should do one or
[EMAIL PROTECTED] writes:
The command that generated this: jpegtran -rotate 90 -copy all
file.jpg ~/.emacs.d/tumme/.tumme_rotate_temp
The problem is that the fails if the file already exists.
So I made a change to tumme-rotate-original that checks if that
file is there and deletes it
Nick Roberts [EMAIL PROTECTED] writes:
Really strange. I rotate images all the time with tumme and I
have never seen this problem. Normally has no problem
overwriting old files.
twurgl probably uses a csh variant and has set noclobber while you
don't.
In that case, applying this
Would having 'set -o noclobber' in one of /bin/sh's startup files
explain it?
/bin/sh has only one startup file (/etc/profile and/or ~/.profile) which is
only sourced for login shells, so no that wouldn't explain it.
I see now that jpegtran has an option, -outfile:
-outfile name
I tried the -outfile ~/.emacs.d/tumme/.tumme_rotate_temp from the command line;
it works great.
It overwrites the old outfile.
Is it OK to commit a fix for this now?
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
Stefan Monnier [EMAIL PROTECTED] writes:
Bash has other startup files.
Not when executed as /bin/sh AFAIK (in non-login shells at least).
This is specifically by design for those kinds of reasons we're
seeing here.
In this particular place we call the command like this:
(if (not (= 0
Mathias Dahl [EMAIL PROTECTED] writes:
In this particular place we call the command like this:
(if (not (= 0 (call-process shell-file-name nil nil nil
shell-command-switch command)))
Hehe, forgot my point :) What I was trying to say was that in my case
shell
Stefan Monnier [EMAIL PROTECTED] writes:
shell-file-name is /bin/bash.
That's the bug. `shell-file-name' should be /bin/sh.
Really? The doc says:
shell-file-name is a variable defined in `C source code'.
Its value is /bin/bash
Documentation:
*File name to load inferior shells
Has anyone else noticed anything strange about the completion in
`find-file' after building from today's code?
This is what happens for me:
C-x C-f; find-file
/big/dat ; I just starts typing here, and this folder exists
TAB; To complete the path
Emacs now displays this:
Find
Romain Francoise [EMAIL PROTECTED] writes:
Has anyone else noticed anything strange about the completion in
`find-file' after building from today's code?
Yes, same problem here. It's caused by the following change, and
can be reproduced easily by enabling partial-completion-mode.
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
`browse-url-file-url' returns an URL that looks like
file:c:/full/path-to-file.css
at least on w32. Such an URL does not work in for example a
link href=... rel=StyleSheet /
tag in Firefox in an xhtml file. I would expect this to be a
Stephen Berman [EMAIL PROTECTED] writes:
Yesterday I tried tumme again for the first time since last August
and encountered problems I don't recall having before. I found a
very easy fix, by changing the default custom settings of two
variables, but these defaults have been around a long
Tassilo Horn [EMAIL PROTECTED] writes:
Here, the thumbs are displayed properly, and RET opens a
*tumme-display-image* buffer with a scaled image. (The original icon
is 64x64, and the buffer shows about a 350x350 version)
When I type `f' a small, empty square is displayed -- not the
image.
Richard Stallman [EMAIL PROTECTED] writes:
I was able to recreate this, but only for small images. Not sure yet
if there is a certain limit or if it is variable. The same problem can
be seen if you do C-u RET instead of RET in the thumbnail buffer.
I cannot say if this ever
42 matches
Mail list logo
