Re: Unify PTY handling
24 years, 6 months
Florian Weimer
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
> Also we should pay close attention to Linux/glibc-isms. The code in
> question is conditioned on HAVE_GETPT, but this refers to a GNU
> extension in glibc which appears to be a convenience routine.
getpt() is not a convinience routine. It is required for UNIX98 PTY
emulation with glibc 2.1 on Linux 2.0. There's no master PTY device
on such systems.
> It's quite possible that other systems will comply with the …
[View More]standard
> (Unix9X?) and could take advantage of the apparently more careful
> code in the Linux s/m file, but won't have getpt() -- or at least we
> should check on that.
Other system do support these PTY style, but the master PTY device is
named differently, and some systems require special STREAMS setup
stuff. Finally, HP-UX grantpt() doesn't do what the manpage says.
As a result, when I wrote the patch for GNU Emacs, I discarded the
idea of unifying UNIX98 PTY support. It would still require a bunch
of #defines and would be nearly as ugly as the current solution (on
GNU Emacs).
(Due to legal reasons, GNU Emacs does not ship with the RUS-CERT
patch.)
--
Florian Weimer Florian.Weimer(a)RUS.Uni-Stuttgart.DE
University of Stuttgart http://cert.uni-stuttgart.de/
RUS-CERT +49-711-685-5973/fax +49-711-685-5898
http://ca.uni-stuttgart.de:11371/pks/lookup?op=get&search=0xC06EC3B5
[View Less]
vertical-mode.el
24 years, 6 months
Steve Youngs
What's the general census of opinion of this little thing, is it
something that could go into edit-utils? Are there any reasons why it
shouldn't be included?
==================================================
;; Copyright (C) 1998-2000 Pavel Machek <pavel(a)ucw.cz>
;;
;; Author: Pavel Machek <pavel(a)ucw.cz>
;;; Commentary:
; This minor mode allows you to conviently edit things that are oriented vertically
; (like tables in computer programs): after each action, cursor moves …
[View More]down. Therefore,
; to move block of text to the right, you simply enter vertical mode and then hold
; spacebar, waiting for autorepeat to do the job for you.
;; Put this file into your load-path and the following into your ~/.emacs:
;; (require 'vertical-mode)
;;; Code:
(defun vertical-after-change (from to num)
"Function called after each change of text in vertical minor mode"
(goto-char vertical-goto-point)
(next-line 1))
(defun vertical-before-change (from to)
(setq vertical-goto-point from)
(setq vertical-goto-column (current-column)))
(defvar vertical-mode nil
"Vertical mode")
(make-variable-buffer-local 'vertical-goto-point)
(make-variable-buffer-local 'vertical-goto-column)
(make-variable-buffer-local 'vertical-mode)
(defun vertical-mode (&optional arg)
"This function toggles vertical mode on and off."
(interactive)
(setq vertical-mode
(if (null arg) (not vertical-mode)
(> (prefix-numeric-value arg) 0)))
(force-mode-line-update)
(make-local-hook 'before-change-functions)
(make-local-hook 'after-change-functions)
(if vertical-mode
(progn
(add-hook 'before-change-functions 'vertical-before-change nil t)
(add-hook 'after-change-functions 'vertical-after-change nil t))
(progn
(remove-hook 'before-change-functions 'vertical-before-change t)
(remove-hook 'after-change-functions 'vertical-after-change t))))
(setq
minor-mode-alist (cons
'(vertical-mode " Vertical") minor-mode-alist))
(provide 'vertical-mode)
;;; vertical-mode.el ends here
--
|---<Regards, Steve Youngs>-----------[GnuPG KeyID: EFD82ED2]---|
| XEmacs - It's not just an editor... |
| It's a way of life. |
|----------------------------------<mailto:youngs＠xemacs.org>---|
[View Less]
Fix for completion list being too wide.
24 years, 6 months
Mehul A. Shah
I had a problem with the completion lists for file-completion or
buffer-name completion earlier this year. When I split my frame into two
vertically adjoining buffers, the list would be too wide and thus scroll
off the screen. I would then have to pick-up my mouse to see the whole
list. Below is a quick solution I found to the problem, and it seems to
work in most cases. I thought I would share it with you guys.
Later,
Mehul
------------------------------------
Mehul Shah wrote:
>
…
[View More]> Regarding my previous post about the Completion list being too wide,
I
> could not find a configuration option that allowed me to fix the
> problem.
>
> Instead, what I had to do is read through the system lisp files to
find
> the appropriate functions that were called when displaying the
> completion list.
>
> The problem seems to have to with the "with-output-to-temp-buffer"
> function which is used throughout. It does not display the temp
buffer
> in a window until the display-completion-list is completed. The
> display-completion-list function does the formatting, and defaults to
> the width of the *frame* not the *window*, which is why the
completion
> list is too wide. The only way to get the width of the window is to
> display empty output to a temp-buffer and then call it again with the
> output of the display-completion-list buffer. For file completions,
in
> the file list-mode.el, the function minibuffer-completion-help, I
added
> a dummy call:
>
> (with-output-to-temp-buffer *Completions* ())
>
> to display the *Completions* window.
>
> Then in minibuf.el, in read-file-name-1 in the call to
> display-completion-list
>
> I added
>
> :window-width (window-width (get-buffer-window (get-buffer
> "*Completions*")))
>
> This fixed the Completion list window being too wide for reading in
> file-names. However this does not fix the Completion lists when
> switching buffers or when looking for a command with M-x. I can't
seem
> to find the code where the display-completion-list function call is
for
> these completion commands. Can anyone help?
>
> Thanks,
>
> Mehul
Ignore the hack above, here is a better solution.
Okay, I have found a reasonable solution to the *Completion* list being
too wide problem. Here is the quick fix, although I believe the code
should be restructured so
that the temporary buffer is displayed before its contents are
formatted. This way, the code does not have to guess at what the width
is of the window in which the
temporary buffer is displayed.
In list-mode.el previously, in the function display-completion-list,
the width of the window was guessed with the following code:
(frame-width (or (last-nonminibuf-frame)
(selected-frame)))
Basically, guessing that the width of the completion window would be
the same as the width of the last selected frame or the width of the
last non-minibuffer frame.
Unfortunately, this is no the case when you split the frame vertically.
So here is a better guess:
(window-width (get-lru-window (last-nonminibuf-frame)))
This basically gets the width of the least recently used window, which
happens to be the window in which the temp buffer tends to get displayed
in. I have not verified
this fact in the code, but seems to work when I use it.
So, in list-mode.el I simply replaced the previous guess with the new
one and the formatting came out much better (both in cases where a new
window is created for
the temp buffer and one in which there is an available window for the
temp buffer).
Thanks,
Mehul
[View Less]
Re: [PB] compiling psgml from cvs
24 years, 6 months
Steve Youngs
* Didier Verna <didier(a)xemacs.org> writes:
> The compilation process of the psgml CVS tree doesn't work for me.
> Here's where it fails (this is the most recent cvs tree):
> /usr/local/src/xemacs/src/xemacs -batch -vanilla -eval "(push (expand-file-name \".\") load-path)" \
> -l psgml-parse \
> -eval "(setq sgml-auto-activate-dtd t \
> sgml-data-directory (expand-file-name \"etc\") \
> sgml-ecat-files (list (expand-file-…
[View More]name \"ECAT\" sgml-data-directory)) \
> sgml-catalog-files (list (expand-file-name \"CATALOG\" sgml-data-directory)))" \
> -f sgml-compile-all-dtds
> Wrong type argument: stringp, nil
> xemacs exiting
> .
> That seems to come from this target in the Makefile:
> # We should make a dependency on all files in etc/cdtd - but
> # how can this be done? Nevertheless the following should work.
> etc/cdtd/html: etc/ECAT etc/CATALOG etc/*.dtd etc/*.ent $(DATA_2_FILES)
> mkdir -p etc/cdtd
> $(XEMACS) -batch -vanilla -eval "$(EXTEND_LOAD_PATH)" \
> -l psgml-parse \
> -eval "(setq sgml-auto-activate-dtd t \
> sgml-data-directory $(SGML_DATA_DIRECTORY) \
> sgml-ecat-files (list $(SGML_ECAT_FILES)) \
> sgml-catalog-files (list $(SGML_CATALOG_FILES)))" \
> -f sgml-compile-all-dtds
Strange, I have no problems here (Linux x86, complete XEmacs packages
CVS tree).
Do you have permission to create etc/cdtd ?
--
|---<Regards, Steve Youngs>-----------[GnuPG KeyID: EFD82ED2]---|
| XEmacs - It's not just an editor... |
| It's a way of life. |
|----------------------------------<mailto:youngs＠xemacs.org>---|
[View Less]
[PB] compiling psgml from cvs
24 years, 6 months
Didier Verna
The compilation process of the psgml CVS tree doesn't work for me.
Here's where it fails (this is the most recent cvs tree):
/usr/local/src/xemacs/src/xemacs -batch -vanilla -eval "(push (expand-file-name \".\") load-path)" \
-l psgml-parse \
-eval "(setq sgml-auto-activate-dtd t \
sgml-data-directory (expand-file-name \"etc\") \
sgml-ecat-files (list (expand-file-name \"ECAT\" sgml-data-directory)) \
sgml-catalog-files (list (expand-file-name \"…
[View More]CATALOG\" sgml-data-directory)))" \
-f sgml-compile-all-dtds
Wrong type argument: stringp, nil
xemacs exiting
.
That seems to come from this target in the Makefile:
# We should make a dependency on all files in etc/cdtd - but
# how can this be done? Nevertheless the following should work.
etc/cdtd/html: etc/ECAT etc/CATALOG etc/*.dtd etc/*.ent $(DATA_2_FILES)
mkdir -p etc/cdtd
$(XEMACS) -batch -vanilla -eval "$(EXTEND_LOAD_PATH)" \
-l psgml-parse \
-eval "(setq sgml-auto-activate-dtd t \
sgml-data-directory $(SGML_DATA_DIRECTORY) \
sgml-ecat-files (list $(SGML_ECAT_FILES)) \
sgml-catalog-files (list $(SGML_CATALOG_FILES)))" \
-f sgml-compile-all-dtds
--
/ / _ _ Didier Verna http://www.inf.enst.fr/~verna/
- / / - / / /_/ / EPITA / LRDE mailto:didier＠lrde.epita.fr
/_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77
94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99
[View Less]
Re: C/C++ Code Browsing
24 years, 6 months
Andrew J Cosgriff
Stephen J. Turnbull wrote :
> >>>>> "mb" == Martin Buchholz <martin(a)xemacs.org> writes:
>
> mb> This sort of simple thing [toggle .cpp v .h files] is
> mb> something for users to define in their .emacs.
>
> Your function doesn't work as a toggle, it only goes one way.
>
> mb> Should support for something like this be in cc-mode?
>
> Most of the time when Alt-S would be a convenience, C-x b RET does the
> same …
[View More]thing, no?
>
> If the user really wants
> `find-file-corresponding-implementation-or-interface' we should give
> it to them, but the first response should be "This is `tags'. Doesn't
> tags do what you need, better?"
>
> Frankly, I see no need.
I've got a vague memory of some package that did this kinda .c <=> .h
file swapping a few years ago, although since I didn't need it at the
time, its name escapes me...
--
Andrew J Cosgriff <ajc(a)polydistortion.net> may be susceptible to sunspots
[View Less]
Re: C/C++ Code Browsing
24 years, 6 months
Steve Youngs
* Martin Buchholz <martin(a)xemacs.org> writes:
> This sort of simple thing is something for users to define in their .emacs.
> (add-hook
> 'c-mode-common-hook
> (lambda ()
> (local-set-key [(meta s)]
> (lambda ()
> (interactive)
> (find-file-other-window
> (replace-in-string buffer-file-name "\\.cpp" ".h"))))))
> Should support for something like this be in cc-mode?
Probably not. Even a fairly small project would probably …
[View More]have two or
more header files included in each source file. They can't all have
the same name, and as you said, Martin, it's the sort of thing that a
user would put into their .emacs.
But perhaps something that prompted for a filename (sans extension)
with the name of the current filename as the default could be better?
--
|---<Regards, Steve Youngs>-----------[GnuPG KeyID: EFD82ED2]---|
| XEmacs - It's not just an editor... |
| It's a way of life. |
|----------------------------------<mailto:youngs＠xemacs.org>---|
[View Less]
Changing the size of italic-face
24 years, 6 months
Volker Franz
Hi,
I appended a more detailed description of the problem, giacomo boffi
was already announcing (Subject: "bug: bold face").
In short: Changing the size of italic-face (and also of bold-face) via
customize does not work (I did exactly the same for my "old" XEmacs
21.1 - and everything worked fine).
Volker
======================================================================
- XEmacs related .Xresources:
XEmacs.geometry: 85x34+0+0
=====================================================…
[View More]=================
- Test whether standard font and desired font for italic exist:
$xfontsel -pattern '-*-courier-medium-i-*-*-*-120-*-*-*-*-iso8859-*'
$xfontsel -pattern '-*-courier-medium-i-*-*-*-240-*-*-*-*-iso8859-*'
======================================================================
- Start xemacs-beta (XEmacs 21.2 (beta35) "Nike" [Lucid] (i586-pc-linux)):
$xemacs-21.2-b35 -no-init-file
- Test initial setting of italic face:
M-x hyper-describe-face RET italic RET
`italic' (buffer: *scratch*, mode: Lisp Interaction)
Face:
ABCDEFHIJKLMNOPQRSTUVWXYZ abcdefhijklmnopqrstuvwxyz 0123456789
Font: -*-courier-medium-i-*-*-*-120-*-*-*-*-iso8859-*
Foreground: (black)
Background: (gray80)
Underline: (nil)
Italic text.
- Changing italic face via customize to 24pt:
M-x customize-face RET italic RET
- Test new setting of italic face:
M-x hyper-describe-face RET italic RET
`italic' (buffer: *Customize Face: Italic*, mode: Custom)
Face:
ABCDEFHIJKLMNOPQRSTUVWXYZ abcdefhijklmnopqrstuvwxyz 0123456789
Font: -*-courier-medium-i-*-*-*-120-*-*-*-*-iso8859-*
Foreground: (black)
Background: (gray80)
Underline: nil
Italic text.
Property-list:
face-comment: nil
customized-face-comment: nil
custom-face-display: t
customized-face: ((t (:size "24pt" :italic t)))
======================================================================
- Start "old" xemacs (XEmacs 21.1 (patch 9) "Canyonlands" [Lucid] (i586-pc-linux)):
$xemacs-21.1.9 -no-init-file
- Test initial setting of italic face:
M-x hyper-describe-face RET italic RET
`italic' (buffer: *scratch*, mode: Lisp Interaction)
Face:
ABCDEFHIJKLMNOPQRSTUVWXYZ abcdefhijklmnopqrstuvwxyz 0123456789
Font: -*-courier-medium-i-*-*-*-120-*-*-*-*-iso8859-*
Foreground: (black)
Background: (gray80)
Underline: (nil)
Italic text.
- Changing italic face via customize to 24pt (customize-face "italic")
M-x customize-face RET italic RET
- Test new setting of italic face:
M-x hyper-describe-face RET italic RET
`italic' (buffer: *scratch*, mode: Lisp Interaction)
Face:
ABCDEFHIJKLMNOPQRSTUVWXYZ abcdefhijklmnopqrstuvwxyz 0123456789
Font: -*-courier-medium-i-*-*-*-240-*-*-*-*-iso8859-*
Foreground: (black)
Background: (gray80)
Underline: nil
Italic text.
Property-list:
custom-face-display: t
customized-face: ((t (:size "24pt" :italic t)))
======================================================================
[View Less]
Re: Question about HTML mode of XEmacs
24 years, 6 months
Adrian Aichner
>>>>> "APA" == Adrian Aichner <aichner(a)ecf.teradyne.com> writes:
APA> I strongly recommend it. I use it to automatically validate all
APA> website content at http:/xemacs.sourceforge.net
Brrr, should be http://xemacs.sourceforge.net/
--
Adrian Aichner <adrian(a)xemacs.org>