headers
Peter Dyballa | 1 Nov 2011 01:24
Picon
Favicon

bug#9927: 24.0.90; unexec/unexmacosx fails with GCC 4.6.1 on intel Mac OS X 10.6.8

Hello!

Configuration with a modified configure script (see bug#9755) and compilation are fine, until it's time
to create emacs from temacs:

	--- Load Commands written to Output File ---
	Writing segment __PAGEZERO        <at>         0 (       0/  0x1000  <at>           0)
	Writing segment __TEXT            <at>         0 (0x1b2000/0x1b2000  <at>      0x1000)
	Writing segment __DATA            <at>  0x1b2000 (0x1dc000/0x1dc000  <at>    0x1b3000)
	        section __dyld           at 0x1b2000 - 0x1b201c (sz:     0x1c)
	        section __nl_symbol_ptr  at 0x1b201c - 0x1b2b08 (sz:    0xaec)
	        section __la_symbol_ptr  at 0x1b2b08 - 0x1b36d0 (sz:    0xbc8)
	        section __const          at 0x1b36d0 - 0x1b4b08 (sz:   0x1438)
	        section __data           at 0x1b4b10 - 0x349c92 (sz: 0x195182)
	unexec: unrecognized section name in __DATA segment

Before it was reported:

	2 LC_SEGMENT            736 __DATA             0x1b3000 0x1dc000
	                           __dyld             0x1b3000     0x1c
	                           __nl_symbol_ptr    0x1b301c    0xaec
	                           __la_symbol_ptr    0x1b3b08    0xbc8
	                           __const            0x1b46d0   0x1438
	                           __data             0x1b5b10 0x195182
	                           __static_data      0x34ac92      0x3
	                           __pu_bss2          0x34ac98   0x5418
	                           __pu_bss4          0x3500b0   0x8634
	                           __bss2             0x3586e4  0x2faec
	                           __bss4             0x3881d0   0x6564
(Continue reading)

Permalink | Reply | 3 comments |
headers
Oleksandr Gavenko | 1 Nov 2011 10:29
Picon

bug#9920: 23.2; Not trusting file .hg/hgrc from untrusted user... for 'vc-hg.el'.

31.10.2011 22:26, Dan Nicolaescu пишет:
> Oleksandr Gavenko<gavenko <at> bifit.com.ua>  writes:
>
>> Under Debian I have:
>
> What version of emacs are you using?
> emacs-23.3 and emacs-snapshot do not set HGRCPATH anymore, so you should
> not see this issue.
>
23.2 as this in subj.

As you wrote I think updating Emacs to new version resolve my issue...

Currently I can not update Emacs version without additional effort
as Debian does not provide Emacs 23.3 in "stable".

--

-- 
С уважением, Александр Гавенко.
Permalink | Reply | 1 comment |
headers
Juri Linkov | 1 Nov 2011 10:27
Favicon
Gravatar

bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode

>> When I type `M-x calc RET h h', it displays the *Help* window in the
>> Calc window that is too small to read comfortably the Help buffer.
>>
>> That's because I have in .emacs:
>> (add-to-list 'same-window-buffer-names "*Help*")
>>
>> Is it possible to display the Help buffer in another window in this case
>> when `h h' is typed in the Calc window?
>
> I'm not sure what you want, since you are explicitly telling Emacs to
> display Help in the same window.  Is that line from your .emacs for some
> other *Help* buffer, and you never want the Calc help to appear in the
> same window?  Perhaps if the Calc help were named "*Calc Help*" (or
> better, perhaps, using a variable to determine the name,
> `calc-help-buffer-name' or somesuch).  That wouldn't be hard, but
> perhaps should wait until after 24.1.

Some modes bind `same-window-buffer-names' to nil when it makes no sense
to display the *Help* or *Info* buffer in the same window when it is
too small, thus overridding the user's settings.

IIUC, with the new window rules, the right way to do this is to bind
`display-buffer-overriding-action' to `display-buffer-pop-up-window'.
But this doesn't work as expected:

(let ((display-buffer-overriding-action '(display-buffer-pop-up-window)))
  (with-output-to-temp-buffer "*Help*"
    (princ "GNU Emacs Calculator.\n")))

It still displays the *Help* buffer in the same window when
(Continue reading)

Permalink | Reply | 22 comments |
headers
Juri Linkov | 1 Nov 2011 10:35
Favicon
Gravatar

bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer

> When you are in a narrowed buffer (e.g. an Info buffer), the line
> number that you see in the mode-line is relative to the narrowed
> portion, whereas the `goto-line' (M-g g) command requires you to
> supply an absolute line number.
>
> This discrepancy is quite confusing for users, so my proposal is
> obvious: adjust the behaviour of `goto-line' to make it consistent
> with the line number showed in the minibuffer, i.e, to consider its
> LINE argument relative to the narrowed part if there's one, or else to
> the whole buffer.

Just removing `(widen)' from `goto-line' will fix this.  But the question is
why it's here.  What was the intention of adding `(widen)' here.
Permalink | Reply | 6 comments |
headers
Juri Linkov | 1 Nov 2011 10:29
Favicon
Gravatar

bug#9891: 24.0.90; Duplicated entry at the info directory

> This is not specific to your setup.  Emacs deliberately includes in
> Info-directory-list both the source and the installation directories.

I think duplicate entries is not a problem.  The problem is that
selecting a menu entry from the installation directory navigates
to the manual from the source directory, because their filenames
are not absolute in `dir'.  This is too confusing.  I think that
menu entries from the installation directory should lead to the manuals
in the installation directory, and menu entries from the source
directory should lead to the manuals in the source directory.
Permalink | Reply | 15 comments |
headers
Juri Linkov | 1 Nov 2011 10:32
Favicon
Gravatar

bug#9915: 24.0.91; Info-hide-node-references does not take effect immediately

> Use "M-x customize-variable" to customize the variable
> Info-hide-node-references to a nil value.  Then return to the *info*
> buffer.
>
> Expected result: the above line shows the full reference, as in
>
>   For information on extending Emacs, see *note Emacs Lisp: (elisp)Top.
>
> Actual result: the display does not change, until you leave this node
> and return to it, or manually invoke revert-buffer.

Is this what you want?

=== modified file 'lisp/info.el'
--- lisp/info.el	2011-10-30 14:37:48 +0000
+++ lisp/info.el	2011-11-01 09:30:42 +0000
 <at>  <at>  -231,6 +231,12  <at>  <at>  (defcustom Info-hide-note-references t
 		 (const :tag "Replace tag and hide reference" t)
 		 (const :tag "Hide tag and reference" hide)
 		 (other :tag "Only replace tag" tag))
+  :set (lambda (sym val)
+	 (set sym val)
+	 (dolist (buffer (buffer-list))
+	   (with-current-buffer buffer
+	     (when (eq major-mode 'Info-mode)
+	       (revert-buffer t t)))))
   :group 'info)

 (defcustom Info-refill-paragraphs nil
(Continue reading)

Permalink | Reply | 4 comments |
headers
Dani Moncayo | 1 Nov 2011 10:39
Picon

bug#9918: 24.0.90; lazy-highlighting in Info mode

> But Info Isearch sets `isearch-error' to "initial node", so
> `isearch-lazy-highlight-new-loop' doesn't start lazy-highlighting.
> It seems with the error "initial node", it's still possible to
> lazy-highlight other matches.  So it's not a normal error,
> and we can make an exception for this type of "error".
> This will work with the following patch:
>
> [...]
>
> But it's not good to hardcode it, so perhaps we should introduce
> a special property for errors that are not quite an error,
> and set it just for "initial node".

Indeed.

IIUC, "initial node" just inform the user that the current search is
failing inside this node (where the search started), but this should
not be considered an error (like "incomplete input" or "No previous
search string"), because "initial node", unlike "incomplete input",
does not deactivate the current Isearch.

So, I think that maybe TRT would be to move the "inital node" message
to the Isearch prompt, so that such prompt would be "Failing I-search
(initial node): ".

BTW: while looking for sentences that set the value of `isearch-error'
inside lisp/isearch.el, I've noticed that some errors begins with an
uppercase letter ("No previous search string") and others don't
("incomplete input").  This should be fixed to make it consistent for
all error messages.
(Continue reading)

Permalink | Reply | 11 comments |
headers
Dani Moncayo | 1 Nov 2011 11:21
Picon

bug#9918: 24.0.90; lazy-highlighting in Info mode

BTW, whatever the patch be, there is a second issue (discovered by
Drew) that should be addressed:

The first time Isearch is fails inside an Info node, you get the
"initial node" message, and then, typing another "C-s" have the effect
of continuing the Isearch across subsequent info nodes.  But this
behavior sometimes fails.  For example:

1. Go to Info node "(emacs)Intro".
2. Type "C-s extensible C-s C-s".
--> Here you've got the "initial node" message. OK.
3. Type "C-s".
--> (Observed) The "initial node" message is removed, and everything
remains the same.  You have to type "C-s" again to continue the search
in subsequent nodes.
--> (Expected) The Isearch is continued across subsequent nodes,
without the need of an extra "C-s".

--

-- 
Dani Moncayo
Permalink | Reply | 0 comments |
headers
Eli Zaretskii | 1 Nov 2011 12:18
Picon

bug#9915: 24.0.91; Info-hide-node-references does not take effect immediately

> From: Juri Linkov <juri <at> jurta.org>
> Cc: 9915 <at> debbugs.gnu.org
> Date: Tue, 01 Nov 2011 11:32:35 +0200
> 
> > Use "M-x customize-variable" to customize the variable
> > Info-hide-node-references to a nil value.  Then return to the *info*
> > buffer.
> >
> > Expected result: the above line shows the full reference, as in
> >
> >   For information on extending Emacs, see *note Emacs Lisp: (elisp)Top.
> >
> > Actual result: the display does not change, until you leave this node
> > and return to it, or manually invoke revert-buffer.
> 
> Is this what you want?

This works for me, thanks.  But there seems to be a left-over problem
with this change, at least on a TTY: when I finish customizing the
value and hit RET on the "Set for current session" button, Emacs
signals an error:

   custom-variable-set: Selecting deleted buffer

The customization does take effect, this error notwithstanding.
Permalink | Reply | 3 comments |
headers
Eli Zaretskii | 1 Nov 2011 12:32
Picon

bug#9891: 24.0.90; Duplicated entry at the info directory

> From: Juri Linkov <juri <at> jurta.org>
> Cc: Dani Moncayo <dmoncayo <at> gmail.com>,  9891 <at> debbugs.gnu.org
> Date: Tue, 01 Nov 2011 11:29:48 +0200
> 
> > This is not specific to your setup.  Emacs deliberately includes in
> > Info-directory-list both the source and the installation directories.
> 
> I think duplicate entries is not a problem.

If they aren't, then why do we have Info-dir-remove-duplicates?

> The problem is that selecting a menu entry from the installation
> directory navigates to the manual from the source directory, because
> their filenames are not absolute in `dir'.  This is too confusing.
> I think that menu entries from the installation directory should
> lead to the manuals in the installation directory, and menu entries
> from the source directory should lead to the manuals in the source
> directory.

This is not specific to the situation with source and build
directories.  This will happen any time you have identical entries
collected from different DIR files, each one of them referring to a
different copy/version of the same manual.  Info always searches for
each file along Info-directory-list (INFOPATH for the stand-alone Info
reader) in the order of the directories in that list, and displays the
first matching manual it finds.  As long as this is the way it works,
you will be unable to solve this problem.  It's like with searching
exec-path for executable programs or load-path for Lisp libraries.

Even if you convert the file names in DIR entries to absolute form
(Continue reading)

Permalink | Reply | 14 comments |

Gmane