call function in other window ?

call function in other window ?

[Jean-Christophe Helary]

Is there an argument to M-x... to call a function not in the current buffer/window but in a different one (like the one targeted by "other window" ? Or a different way to do that ?

Jean-Christophe Helary 

RE: call function in other window ?

[Drew Adams]

> Is there an argument to M-x... to call a function not in the current
> buffer/window but in a different one (like the one targeted by "other
> window" ? Or a different way to do that ?

(defun foo (fn &rest args)
  (let ((win  (next-window)))
    (when win
      (with-current-buffer (window-buffer win)
	(apply fn args)))))

Re: call function in other window ?

[Jean-Christophe Helary]

Thank you Drew.

Wouldn't it be something that people use frequently enough that is has its own function in Emacs ?

Jean-Christophe 

> On May 21, 2017, at 5:25, Drew Adams <drew.adams@oracle.com> wrote:
> 
>> Is there an argument to M-x... to call a function not in the current
>> buffer/window but in a different one (like the one targeted by "other
>> window" ? Or a different way to do that ?
> 
> (defun foo (fn &rest args)
>  (let ((win  (next-window)))
>    (when win
>      (with-current-buffer (window-buffer win)
> 	(apply fn args)))))

Re: call function in other window ?

[Emanuel Berg]

Jean-Christophe Helary wrote:

> Wouldn't it be something that people use
> frequently enough that is has its own
> function in Emacs ?

I don't think people do this that often.
Probably what people do is `other-window', or
whatever command to get to the desired buffer,
and then M-x their function, then get back...

There are shortcuts, or they can be set up, to
move very rapidly between buffers,
keyboard only.

If you want to optimize a specific case in
Elisp, you could do something like

    (defun do-something-other-window ()
      (interactive)
      (save-window-excursion
        (other-window 1)
        (do-something) ))

Perhaps with a check included to see where you
ended up - at least if "do-something" includes
changing the other buffer.

-- 
underground experts united
http://user.it.uu.se/~embe8573

RE: call function in other window ?

[Drew Adams]

> >> Is there an argument to M-x... to call a function not in the current
> >> buffer/window but in a different one (like the one targeted by "other
> >> window" ? Or a different way to do that ?
> >
> > (defun foo (fn &rest args)
> >  (let ((win  (next-window)))
> >    (when win (with-current-buffer (window-buffer win)
> > 	  (apply fn args)))))
> 
> Thank you Drew.  Wouldn't it be something that people use
> frequently enough that is has its own function in Emacs ?

If you think it's useful to add to Emacs, please file an
enhancement request: `M-x report-emacs-bug' (that's for
enhancement request too, not just bugs).  The request will
be considered, perhaps discussed, and someone will decide
whether to grant it.

I don't know whether others will find such a function useful.
I haven't needed it.  I imagine that most people who are
going to write Lisp code to act on a buffer will know to
use `with-current-buffer', and to get to the buffer of
another window they will use `window-buffer'.  Those are
commonly used.  Whether it is common to want to act on the
buffer in `next-window' is something else.

My guess is that such code is straightforward and short enough
that it won't be thought very useful to have such a function
predefined.  But certainly if someone were going to do exactly
that frequently (e.g. act on the buffer in the `next-window')
then such a function could be handy.  You pose that question:
whether such a need is frequent.  Dunno, but I don't think so.

Re: call function in other window ?

[Emanuel Berg]

Drew Adams wrote:

> I don't know whether others will find such
> a function useful. I haven't needed it.

Look, I used it! Previously I had
`other-window' in both kill functions.
This is neater.

    (defun apply-in-other-window (fn &rest args)
      (let*((window (next-window))
            (buffer (and window (window-buffer window)) ))
        (when buffer
          (with-current-buffer buffer
            (apply fn args) ))))

    (defun kill-path-other-window ()
      (interactive)
      (apply-in-other-window #'kill-path) )

    (defun kill-name-other-window ()
      (interactive)
      (apply-in-other-window #'kill-name) )

> I imagine that most people who are going to
> write Lisp code to act on a buffer will know
> to use `with-current-buffer', and to get to
> the buffer of another window they will use
> `window-buffer'. Those are commonly used.

Well, what should determine if something should
be included or not is its usefulness. As for
the difficulty implementing this particular
function, I'd put it somewhere in the
mid range. But again, that shouldn't influence.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: call function in other window ?

[Jean-Christophe Helary]

Thanks everybody for the replies.

It maybe that my workflow does not include (yet) methods that are specific to the way emacs works. I'll try to see specifically what I want and why I want it that way and will get back to this thread. Thank you again.

Jean-Christophe 

> On May 21, 2017, at 7:43, Jean-Christophe Helary <jean.christophe.helary@gmail.com> wrote:
> 
> Thank you Drew.
> 
> Wouldn't it be something that people use frequently enough that is has its own function in Emacs ?
> 
> Jean-Christophe 
> 
>> On May 21, 2017, at 5:25, Drew Adams <drew.adams@oracle.com> wrote:
>> 
>>> Is there an argument to M-x... to call a function not in the current
>>> buffer/window but in a different one (like the one targeted by "other
>>> window" ? Or a different way to do that ?
>> 
>> (defun foo (fn &rest args)
>> (let ((win  (next-window)))
>>   (when win
>>     (with-current-buffer (window-buffer win)
>> 	(apply fn args)))))
> 

Re: call function in other window ?

[Emanuel Berg]

Jean-Christophe Helary wrote:

> It maybe that my workflow does not include
> (yet) methods that are specific to the way
> emacs works. I'll try to see specifically
> what I want and why I want it that way and
> will get back to this thread.
> Thank you again.

It's a give-and-go game. Let's say you write
three Elisp functions. One you end up never
using. But writing it makes you a better
programmer. The second function you realize
there is already a built-in way to do that
which is better. But because you wrote your own
function you use it for years not realizing the
mistake. The third function tho is really good
and it makes you happy every time you use it.

    Love and pain
    it never stays the same
    or is it just a game ...

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: call function in other window ?

[Jean-Christophe Helary]

> On May 21, 2017, at 19:07, Emanuel Berg <moasen@zoho.com> wrote:
> 
> Jean-Christophe Helary wrote:
> 
>> It maybe that my workflow does not include
>> (yet) methods that are specific to the way
>> emacs works. I'll try to see specifically
>> what I want and why I want it that way and
>> will get back to this thread.
>> Thank you again.
> 
> It's a give-and-go game.

Yes, and it's also called reinventing the wheel, when you don't know that the concept of "wheel" exists :)

Kidding aside, for me, it is more important right now to work on information discovery than on writing a few lines of code that I may or may not use in the future. Emacs is so huge that there is always the possibility to just not find what is right under my nose because the information is hard to discover *or* because I would not think of looking for it in the right place.

Sometimes I look up for info on the net, only to discover a link to the Emacs Manual or the Elisp Reference...

Jean-Christophe :)

Re: call function in other window ?

[Joost Kremers]

On Sun, May 21 2017, Jean-Christophe Helary wrote:
> Kidding aside, for me, it is more important right now to work on 
> information discovery than on writing a few lines of code that I 
> may or may not use in the future. Emacs is so huge that there is 
> always the possibility to just not find what is right under my 
> nose because the information is hard to discover *or* because I 
> would not think of looking for it in the right place.

It may help to learn a bit about Info-mode, if you haven't 
already. The Emacs and Elisp manuals have an index, which you can 
access by typing `i'. If you use a package such as ivy or helm, 
you'll see a list of all the index terms (well, only the first 
few, of course) and typing a word will narrow down that list. The 
nice thing about ivy and helm is that what you type doesn't need 
to match the beginning of an index item.

Also, Info-mode has a regex search function, which you can access 
with `s'. Together, `i' and `s' usually help me to find the right 
place in the Info manual without having to go to Google. (Though 
admittedly, Google also helps, sometimes... ;-) )


-- 
Joost Kremers
Life has its moments

Re: call function in other window ?

[Jean-Christophe Helary]

> On May 21, 2017, at 19:50, Joost Kremers <joostkremers@fastmail.fm> wrote:
> 
> 
> On Sun, May 21 2017, Jean-Christophe Helary wrote:
>> Kidding aside, for me, it is more important right now to work on information discovery than on writing a few lines of code that I may or may not use in the future. Emacs is so huge that there is always the possibility to just not find what is right under my nose because the information is hard to discover *or* because I would not think of looking for it in the right place.
> 
> It may help to learn a bit about Info-mode, if you haven't already.

I admit I'm not super proficient with the info-mode, but I have all the PDFs related to Emacs/Elisp in a tabbed window where I can search them at will (including the org-mode manual etc.)

Instead of the info-mode itself, I usually make use of the help system, it's generally better at finding precise information.

Jean-Christophe 

Re: call function in other window ?

[Emanuel Berg]

Jean-Christophe Helary wrote:

> I admit I'm not super proficient with the
> info-mode, but I have all the PDFs related to
> Emacs/Elisp in a tabbed window where I can
> search them at will (including the org-mode
> manual etc.)

The Emacs help and info and manpage buffers are
probably more interactive and fast to deal with
from and with Emacs. PDFs are more like to
print huge manuals free of charge at your
school or work so you can bring some reading
when you travel by train :)

> Instead of the info-mode itself, I usually
> make use of the help system, it's generally
> better at finding precise information.

The help system is for the impatient
programmers. Info-mode is for the real
engineers :)

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: call function in other window ?

[Eli Zaretskii]

> From: Jean-Christophe Helary <jean.christophe.helary@gmail.com>
> Date: Sun, 21 May 2017 20:08:29 +0900
> 
> Instead of the info-mode itself, I usually make use of the help system, it's generally better at finding precise information.

You should use both, IMO.  Info manuals often provide additional
information that expands and enhances the doc strings.

Re: call function in other window ?

[Jean-Christophe Helary]

> On May 22, 2017, at 0:05, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Jean-Christophe Helary <jean.christophe.helary@gmail.com>
>> Date: Sun, 21 May 2017 20:08:29 +0900
>> 
>> Instead of the info-mode itself, I usually make use of the help system, it's generally better at finding precise information.
> 
> You should use both, IMO.  Info manuals often provide additional
> information that expands and enhances the doc strings.

As I wrote, I (still) prefer to read the manuals as PDFs in an external reader. The main advantage is that I can easily move from a manual to another while I can only have one info buffer opened in Emacs, or maybe I have not yet found the way to keep a number of manuals opened at the same time in Emacs.

Jean-Christophe 

Re: call function in other window ?

[Emanuel Berg]

Jean-Christophe Helary wrote:

> As I wrote, I (still) prefer to read the
> manuals as PDFs in an external reader.

If you use Emacs in X or otherwise any GUI
version, can't you view PDFs in Emacs by just
opening them as any other file?

> The main advantage is that I can easily move
> from a manual to another while I can only
> have one info buffer opened in Emacs, or
> maybe I have not yet found the way to keep
> a number of manuals opened at the same time
> in Emacs.

M-2 M-x info

Then ditto M-3 and so on.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: call function in other window ?

[Jean-Christophe Helary]

> On May 22, 2017, at 0:56, Emanuel Berg <moasen@zoho.com> wrote:
> 
> Jean-Christophe Helary wrote:
> 
>> As I wrote, I (still) prefer to read the
>> manuals as PDFs in an external reader.
> 
> If you use Emacs in X or otherwise any GUI
> version, can't you view PDFs in Emacs by just
> opening them as any other file?

Now that you mention that, I'm using the brew system to install Emacs and even though I use the Cocoa version, every time I try to open a PDF I get the file as if it were opened in a text editor and not the rendered PDF. I think I tried to fix that in the past but it was too much work for little benefit since I already have a really nice FOSS PDF reader on Mac.

Jean-Christophe 

Re: call function in other window ?

[Emanuel Berg]

Jean-Christophe Helary wrote:

> Now that you mention that, I'm using the brew
> system to install Emacs and even though I use
> the Cocoa version, every time I try to open
> a PDF I get the file as if it were opened in
> a text editor and not the rendered PDF.
> I think I tried to fix that in the past but
> it was too much work for little benefit since
> I already have a really nice FOSS PDF reader
> on Mac.

Yeah, I use xpdf for PDFs which probably has an
MIT licence. But it is only because I don't use
a GUI Emacs I don't use Emacs for PDFs as well.
What I do with PDFs is check out the result of
compiled LaTeX. But sure, you would anyhow want
a viewer, Emacs or otherwise, for the
occasional Internet file.

Still, compared to the manpages, info files,
and the on-line help system that Emacs offers
viewing material as PDFs that are available in
those forms should at the very least be
heavy-handed and not offer the same
interactiveness as the in-house solutions.

Just sayin'.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: call function in other window ?

[Jean-Christophe Helary]

> On May 23, 2017, at 6:18, Emanuel Berg <moasen@zoho.com> wrote:
> 
> Still, compared to the manpages, info files, and the on-line help system that Emacs offers viewing material as PDFs that are available in those forms should at the very least be heavy-handed and not offer the same interactiveness as the in-house solutions.

Possibly. But most of the documentation I work with is not Emacs specific and generally does not come in anything but PDF. So I don't have many options. But of course, I also use the info system for things I have info versions of.

Jean-Christophe 

Re: call function in other window ?

[Kaushal Modi]

On Mon, May 22, 2017, 6:27 PM Jean-Christophe Helary <
jean.christophe.helary@gmail.com> wrote:

>
> Possibly. But most of the documentation I work with is not Emacs specific
> and generally does not come in anything but PDF. So I don't have many
> options.
>

On that note, have you tried pdf-tools package (available on Melpa)? It's
so convenient that I have started using that as the default PDF viewer. I
need to routinely access some IEEE standards available as PDF, so I have
bound keys to find-file those and they open up in the pdf-view major mode
(doc-view equivalent) by pdf-tools.

> --

Kaushal Modi

Re: call function in other window ?

[Emanuel Berg]

Kaushal Modi wrote:

> On that note, have you tried pdf-tools
> package (available on Melpa)? It's so
> convenient that I have started using that as
> the default PDF viewer. I need to routinely
> access some IEEE standards available as PDF,
> so I have bound keys to find-file those and
> they open up in the pdf-view major mode
> (doc-view equivalent) by pdf-tools.

Hm, see? Maybe I was wrong. Never underestimate
what you can do with Emacs and where it might
take you.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: call function in other window ?

[Emanuel Berg]

Jean-Christophe Helary wrote:

> Possibly. But most of the documentation
> I work with is not Emacs specific and
> generally does not come in anything but PDF.

The PDF format isn't made to be interactive.
It is made to look good, to look the same on
all computers, and to be easy to print.

Depending on what you do with Emacs, and what
PDFs, there might still be some interactive
gain from using Emacs to browse PDFs.
For example there might be URLs and you can
then use Emacs-w3m to browse or bookmark them.
Or if you quote some paragraph from the PDF you
can yank it right into your buffer.

And a couple of such cases. But I suppose there
isn't a huge loss using an external viewer.
There are other cases when brining your stuff
to Emacs is a much bigger gain.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: call function in other window ?

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, May 23, 2017 at 02:19:47AM +0200, Emanuel Berg wrote:
> Jean-Christophe Helary wrote:
> 
> > Possibly. But most of the documentation
> > I work with is not Emacs specific and
> > generally does not come in anything but PDF.
> 
> The PDF format isn't made to be interactive.
> It is made to look good, to look the same on
> all computers, and to be easy to print.

Never underestimate what you can do (or what can be done to you!)
via embedded Javascript in PDFs[1].

cheers

[1] Quoth Wikipedia's entry on PDF:
    "However, there are still some proprietary technologies
     defined only by Adobe, such as Adobe XML Forms Architecture
     (XFA) and JavaScript extension for Acrobat, which are
     referenced by ISO 32000-1 as normative and indispensable for
     the application of the ISO 32000-1 specification."

- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlkj4HAACgkQBcgs9XrR2kY9AACeJr94LmsLCQhqfp5xOtrP01gv
LGgAnjuPtdg9fALXsGWNzq3Bodx8GUV7
=NYfG
-----END PGP SIGNATURE-----

Re: call function in other window ?

[Emanuel Berg]

>> The PDF format isn't made to be interactive.
>> It is made to look good, to look the same on
>> all computers, and to be easy to print.
>
> Never underestimate what you can do (or what
> can be done to you!) via embedded Javascript
> in PDFs[1].

JavaScript in PDFs? I take it as a feather in
my hat I never heard about that!

> [1] Quoth Wikipedia's entry on PDF: "However,
> there are still some proprietary technologies
> defined only by Adobe, such as Adobe XML
> Forms Architecture (XFA) and JavaScript
> extension for Acrobat, which are referenced
> by ISO 32000-1 as normative and indispensable
> for the application of the ISO
> 32000-1 specification."

Crystal clear! I stand corrected.

But maybe we should be content that only Adobe
has that.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: call function in other window ?

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, May 23, 2017 at 09:44:29AM +0200, Emanuel Berg wrote:
> >> The PDF format isn't made to be interactive.
> >> It is made to look good, to look the same on
> >> all computers, and to be easy to print.
> >
> > Never underestimate what you can do (or what
> > can be done to you!) via embedded Javascript
> > in PDFs[1].
> 
> JavaScript in PDFs? I take it as a feather in
> my hat [...]

Glad I helped decorate your hat :)

> > [1] Quoth Wikipedia [...]

[...]

> Crystal clear! I stand corrected.
> 
> But maybe we should be content that only Adobe
> has that.

I wouldn't be so sure (Adobe would sell my grandma if that were
profitable to them). Besides, it seems to be known outside of
Adobe how to "do" Javascript in PDF anyway.

But my main point was the irony: Adobe gains market dominance
(a long story having to do with PostScript, laser printers and
things), imposes a document standard (PDF) touted as open, ISO
and things, especially touted as "safe" for documents (because,
as opposed to PostScript it's *not* a programming language),
then turns around and makes *proprietary* extensions (referenced
from the standard as _normative_. Yikes) to that with an embedded
executable language. Bad, Adobe, bad.

cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlkj61gACgkQBcgs9XrR2kZ9DQCfRJ1eDabAb1UCc0NKV75R2aHS
6EIAnAqKKNQhdJaIS2kVozC+lp0kZ2pJ
=FwJr
-----END PGP SIGNATURE-----

Re: call function in other window ?

[Emanuel Berg]

> I wouldn't be so sure (Adobe would sell my
> grandma if that were profitable to them).
> Besides, it seems to be known outside of
> Adobe how to "do" Javascript in PDF anyway.
>
> But my main point was the irony: Adobe gains
> market dominance (a long story having to do
> with PostScript, laser printers and things),
> imposes a document standard (PDF) touted as
> open, ISO and things, especially touted as
> "safe" for documents (because, as opposed to
> PostScript it's *not* a programming
> language), then turns around and makes
> *proprietary* extensions (referenced from the
> standard as _normative_. Yikes) to that with
> an embedded executable language. Bad,
> Adobe, bad.

Man, how on earth did this happen? It is so
bizarre. Isn't the PDF something that came out
of Xerox PARC and the PostScript stuff in the
70s-80s? While JavaScript is part of the
90s Netscape era with the whole Internet or
"world wide web" mania?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: call function in other window ?

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, May 23, 2017 at 10:14:22AM +0200, Emanuel Berg wrote:
> > I wouldn't be so sure (Adobe would sell my
> > grandma if that were profitable to them).
> > Besides, it seems to be known outside of
> > Adobe how to "do" Javascript in PDF anyway.
> >
> > But my main point was the irony [...]

> Man, how on earth did this happen? It is so
> bizarre. Isn't the PDF something that came out
> of Xerox PARC and the PostScript stuff in the
> 70s-80s? While JavaScript is part of the
> 90s Netscape era with the whole Internet or
> "world wide web" mania?

Historically it's far more interesting than that.
Javascript is an heir to self, right there where
OO, functional, interpreters and compilers meet
(think Jit, for example). A very interesting spot.
Lua and LuaJIT did better, but benefitted a lot
from hindsight and much more freedom: the web's
sucess means there's no backtracking; once some
idea is "out there", it will stay there, to embarras
the designer in eternity, because people are using
it.

It's just the fight for the "user's device's" control
(Applet, Active-X (remember those?) Flash, Silverlight,
Javascript, not in strict order), then the Holy Grail
of Apps and some form of perverted Java (never thought
*that* could be done) in everyone's pocket, car and sex
toy. That's why Free software (the real Free, written
with a big "F") is more important than ever. And not
just the Free software, but awareness out there.

Sorry for the mess. I just got carried away.

Cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlkj+L0ACgkQBcgs9XrR2kZ0lwCfVD89yA7vP8ighcgnRwKhxMWp
QeMAn1bWnhjuFQCSf7TGjcc8ux9ihs2C
=29cA
-----END PGP SIGNATURE-----

Re: call function in other window ?

[Emanuel Berg]

<tomas@tuxteam.de> writes:

> the web's sucess means there's no backtracking; once
> some idea is "out there", it will stay there, to
> embarras the designer in eternity, because people
> are using it.

That's interesting.

To some extent even web technology can change because
one can use it in a new way.

For example, when I first did HTML no one had ever
heard of CSS and those homepages today would be cut in
half to remove all the design and layup stuff.

(Not that that would much improve the quality of the
actual webpages which must have been
extremely immature...)

> then the Holy Grail of Apps and some form of
> perverted Java (never thought *that* could be done)
> in everyone's pocket, car and sex toy. That's why
> Free software (the real Free, written with a big
> "F") is more important than ever. And not just the
> Free software, but awareness out there.

I've heard this from RMS as well but I didn't
understand it that time either. What I can see, the
smartphones are so totally unergonomic so they can't
be used to do creative stuff. Only consumption of
material. That doesn't have to be bad. It depends what
you consume. But the problem is if people use
smartphones instead of computers they can never leave
the "consumer prison". I honestly don't see how FOSS
can improve that. So what exactly is it FOSS is
expected to do for smartphones?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: call function in other window ?

[Jean-Christophe Helary]

> On May 23, 2017, at 21:58, Emanuel Berg <embe8573@student.uu.se> wrote:
> 
> What I can see, the smartphones are so totally unergonomic so they can't be used to do creative stuff.

Caves were not ergonomic either and yet Palaeolithic people managed to be very creative. Don't underestimate the power of people.

Jean-Christophe

Re: call function in other window ?

[Emanuel Berg]

Jean-Christophe Helary
<jean.christophe.helary@gmail.com> writes:

> Caves were not ergonomic either and yet Palaeolithic
> people managed to be very creative.
> Don't underestimate the power of people.

Caves are ergonomic and they provide space for
ergonomic creations. How are you going to get a decent
keyboard and monitor by putting FOSS in a smartphone?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: call function in other window ?

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, May 23, 2017 at 03:14:13PM +0200, Emanuel Berg wrote:
> Jean-Christophe Helary
> <jean.christophe.helary@gmail.com> writes:
> 
> > Caves were not ergonomic either and yet Palaeolithic
> > people managed to be very creative.
> > Don't underestimate the power of people.
> 
> Caves are ergonomic and they provide space for
> ergonomic creations. How are you going to get a decent
> keyboard and monitor by putting FOSS in a smartphone?

Ways of doing things will change. What I'm more afraid of is that
there's a big economic pressure towards "captive" environments,
which try to hold users hostage. You need a big investment to
get something like a smartphone out in viable quantities. You
don't want your customers to escape your embrace.

Cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlkkixcACgkQBcgs9XrR2kb3NwCfdj6STduP1qvU5HIc8mynNg2A
SpwAn375BSLZ1qmGPCcM66uSo8mmdvp1
=WP71
-----END PGP SIGNATURE-----

Re: call function in other window ?

[Tomas Nordin]

tomas@tuxteam.de writes:

> Never underestimate what you can do (or what can be done to you!)
> via embedded Javascript in PDFs[1].
>
> cheers
>
> [1] Quoth Wikipedia's entry on PDF:
>     "However, there are still some proprietary technologies
>      defined only by Adobe, such as Adobe XML Forms Architecture
>      (XFA) and JavaScript extension for Acrobat, which are
>      referenced by ISO 32000-1 as normative and indispensable for
>      the application of the ISO 32000-1 specification."

And in Sweden the tax authority offer only that kind of PDF for filling
in you bank account number to get taxes back that you payed too much.
Could not open it on my computer. A prominent message is displayed
instead of the expected content, that you should go and install Adobe
PDF reader. They had to send it to me by post. I feel alone in the
entire country complaining about it, but I hope I am wrong. But I am
pretty sure I am about right.

Now one cannot even simply suggest PDF format as opposed to doc or what
have you. You have to specifically suggest not to use a version that
require the Adobe reader. And be sure, soon enough the general view of
this is that people feel that they are behind if they cannot view this
kind of PDF and they rush to install the Adobe reader. 

Best regards
--
Tomas

Re: call function in other window ?

[John Ankarström]

On May 23, 2017 10:25:56 PM GMT+02:00, Tomas Nordin <tomasn@posteo.net> wrote:
> I feel alone in the
> entire country complaining about it, but I hope I am wrong. But I am
> pretty sure I am about right.
You are certainly not alone, but we are probably very few...

Re: call function in other window ?

[Emanuel Berg]

John Ankarström <john@ankarstrom.se> writes:

>> I feel alone in the entire country complaining
>> about it, but I hope I am wrong. But I am pretty
>> sure I am about right.
>>
> You are certainly not alone, but we are probably
> very few...

I'm Swedish too and never had that problem. One of
many advantages with not having an income :)

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: call function in other window ?

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, May 23, 2017 at 10:25:56PM +0200, Tomas Nordin wrote:
> tomas@tuxteam.de writes:
> 
> > Never underestimate what you can do (or what can be done to you!)
> > via embedded Javascript in PDFs[1].
> >
> > cheers
> >
> > [1] Quoth Wikipedia's entry on PDF:
> >     "However, there are still some proprietary technologies
> >      defined only by Adobe [...]

> And in Sweden the tax authority offer only that kind of PDF for filling
> in you bank account number to get taxes back that you payed too much.

Yes, the fight for freedom is always an uphill one. And quite entertaining
since the times immemorial when wolves discovered that they can dress
themselves in the sheep skins they just took as booty :-)

But we won't give up.

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlklNcMACgkQBcgs9XrR2kYk/ACcD55ge+2ynlfDZSeMOJr3dstG
QIQAn31XQyzbWsRwUfvS3kGzG5wTwgMc
=MHZQ
-----END PGP SIGNATURE-----

Re: call function in other window ?

[Eli Zaretskii]

> From: Jean-Christophe Helary <jean.christophe.helary@gmail.com>
> Date: Mon, 22 May 2017 00:14:36 +0900
> 
> As I wrote, I (still) prefer to read the manuals as PDFs in an external reader. The main advantage is that I can easily move from a manual to another while I can only have one info buffer opened in Emacs, or maybe I have not yet found the way to keep a number of manuals opened at the same time in Emacs.

You can have as many Info buffers as you like, just rename them to
*info*<NN> where NN is a number.  Then you can invoke
info-display-manual and get back to the manual you want, or even use
"C-u NN C-h i" if you happen to remember the number.  I routinely have
several dozen Info manuals in my Emacs sessions.

RE: call function in other window ?

[Drew Adams]

> > You should use both, IMO.  Info manuals often provide additional
> > information that expands and enhances the doc strings.
> 
> As I wrote, I (still) prefer to read the manuals as PDFs in an external
> reader. The main advantage is that I can easily move from a manual to
> another while I can only have one info buffer opened in Emacs, or maybe I
> have not yet found the way to keep a number of manuals opened at the same
> time in Emacs.

`M-n' is bound to `clone-buffer' in `Info-mode-map'.  Use it to get
an Info clone of the current node - buffer `*info*<2>' etc.  Then
navigate from either of the two buffers for the node.  Etc.

IOW, you can have as many Info buffers as you like open at the
same time.  Each has its own history (Back etc.).

Remember that in any mode, and Info mode is no exception, `C-h m'
is your friend.  It tells you, among many other things, that `M-n'
selects "a new cloned Info buffer in another window".

Ask Emacs.

RE: call function in other window ?

[Drew Adams]

> You can have as many Info buffers as you like, just rename them to
> *info*<NN> where NN is a number.

It's even easier than renaming them manually.  Just use `M-n'.

> Then you can invoke info-display-manual and get back to the manual
> you want, or even use "C-u NN C-h i" if you happen to remember the
> number.  I routinely hav several dozen Info manuals in my Emacs sessions.

Re: call function in other window ?

[Emanuel Berg]

Jean-Christophe Helary wrote:

> Yes, and it's also called reinventing the
> wheel, when you don't know that the concept
> of "wheel" exists :)

Reinventing the wheel is not necessarily a bad
thing to do. This time a"round" you may
discover something useful. Also, contrary to
what programmers seem to think, a wheel isn't
a trivial implementation of a brilliant
concept. A kid can find a flat, round stone and
roll it to the fireplace to sit on. But the
front wheel of a bike consists at the very
least of a tire, a tube, a rim with rim tape,
spokes with nipples, a socket with flanges,
dome nuts, washers and cone nuts, and an axle
with dust shields, bearings, and grease.

> Kidding aside, for me, it is more important
> right now to work on information discovery
> than on writing a few lines of code that
> I may or may not use in the future.

There is no contradiction. Discovering Emacs
thru code is a fine way of doing it.

> Emacs is so huge that there is always the
> possibility to just not find what is right
> under my nose because the information is hard
> to discover *or* because I would not think of
> looking for it in the right place.

Yeah, what you'd do is get some intuitive feel
of the terminology, and then use `apropos' and
`apropos-command', as well as the describe-'s
(e.g., `describe-function') with TAB
completion. Then check up what you find in the
on-line help. ("On-line" as in not on paper :))

-- 
underground experts united
http://user.it.uu.se/~embe8573